Computed Constants API question

[Maurizio Cimadamore]

Hi,
I believe the issues you see in the JEP reflect the fact that the API 
went through a stage of "late condensation" - we used to 
ComputedConstant and ComputedList, but the latter has now turned into 
just a factory on the former. I think the factory provided is the more 
general (as it allows for different resolution policies).

If I recall correctly, the decision _not_ to provide a List<V> factory 
is motivated by the fact that we would have to respecify that List::get 
is associated with the same behavior as ComputedConstant::get. That is, 
that list can act in very weird ways, throw novel exceptions, etc. For 
these reasons we preferred to make the CC-nature of the list apparent in 
its generic type, rather than introducing some magic list wrapper which 
adds its own special behavior (see Collections::unmodifiableList).

Now, with that said, I can see this going both ways - while List<CC> is 
a more explicit and "honest" representation - what you say re. interop 
with clients accepting just a List<V> is also a valid point (and you 
can't fully get to a List<V> just by using a Steam mapper, as the 
terminal operation `asList` would force eager computation of all the 
constants).

Maurizio

On 28/08/2023 09:31, - wrote:
> Hello Per and Leyden subscribers,
> First, I am glad that we are finally adding an API that exposes one of 
> core libraries' favorite feature, `@Stable`, to common users!
>
> For the API design, however, I have a request: Can we have a 
> ComputedConstant factory that creates a List<V> in addition to one 
> that creates a List<ComputedConstant<V>>?
>
> I think using the List<ComputedConstant<V>> is confusing. The example 
> usages in the JEP [1] and in the API specification [2] are already 
> wrong: we need an extra ConputedConstant.get() call to unwrap the 
> ComputedConstant after List.get(index) call, which currently returns a 
> computed constant than the actual value.
>
> The current List<ComputedConstant<V>> is to be kept in case users want 
> fine-grained control over each constant's resolution failure, etc. and 
> covers the new factory's functionality. But I believe the new factory 
> will see wider usage:
>
> 1. None of the 2 old patterns in the "Motivation" section uses any of 
> these exception handling or initialization state detection.
> 2. Returning a List<V> allows users to conveniently pass the list in 
> usages instead of using streams or writing custom wrappers.
>
> A follow up to a previous request [3], I believe having a map (of type 
> Map<K, V> instead of Map<K, ComputedConstant<V>>) would be feasible too.
>
> Finally, a side comment about the current 
> OnDemandComputedConstantList: it computes ComputedConstant wrappers in 
> addition to the actual constants on demand, which... seems a bit 
> overkill, when ComputedConstant itself is already a lightweight 
> wrapper of a heavy computation?
>
> Best,
> Chen Liang
>
> [1]: https://openjdk.org/jeps/8312611  "var kbd = lbl.labels.get(3);"
> [2]: 
> https://cr.openjdk.org/~pminborg/computed-constant/api/java.base/java/lang/ComputedConstant.html#of(int,java.util.function.IntFunction) 
>  "return PO2_CACHE.get(n);"
> [3]: https://mail.openjdk.org/pipermail/leyden-dev/2023-August/000277.html