<div dir="ltr"><div dir="ltr"><font face="arial, sans-serif">Thanks Maurizio,</font><div><font face="arial, sans-serif">This late condensation does explain the peculiarities in the OnDemandComputedConstantList. And I think not providing a List<V> factory is fine, despite the usage complexities: we still need to track the computation state for each element, so having a CC wrapper over each element isn't too bad.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I think the OnDemandComputedConstantList implementation is unnecessary; we can just create an array of non-null ComputedConstant elements like:</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">ComputedConstant<T>[] array = new ComputedConstant<?>[size]; // unchecked</font></div><div><font face="arial, sans-serif">for (int i = 0; i < size; i++) {</font></div><div><font face="arial, sans-serif">    final int t = i;</font></div><div><font face="arial, sans-serif">    array[i] = of(() -> provider.apply(t));</font></div><div><font face="arial, sans-serif">}</font></div><div><font face="arial, sans-serif">return JUCA.listFromTrustedArray(array);</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Users can use Map.ofEntries to create a Map<K, CC<V>>, but since people might use other types of maps that aren't eligible for Constant-folding, I would recommend providing an official API as well to avoid user errors.</font></div><div><pre style="color:rgb(0,0,0)"><font face="arial, sans-serif">The interloping from List<CC<V>> to List<V> (and also that for Maps) can be implemented by users if needed. It shouldn't be too much of a problem, I would assume.</font></pre></div><div><font face="arial, sans-serif">Chen Liang</font></div></div><font face="arial, sans-serif"><br></font><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><font face="arial, sans-serif">On Mon, Aug 28, 2023 at 5:29 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="arial, sans-serif">Hi,<br>
I believe the issues you see in the JEP reflect the fact that the API <br>
went through a stage of "late condensation" - we used to <br>
ComputedConstant and ComputedList, but the latter has now turned into <br>
just a factory on the former. I think the factory provided is the more <br>
general (as it allows for different resolution policies).<br>
<br>
If I recall correctly, the decision _not_ to provide a List<V> factory <br>
is motivated by the fact that we would have to respecify that List::get <br>
is associated with the same behavior as ComputedConstant::get. That is, <br>
that list can act in very weird ways, throw novel exceptions, etc. For <br>
these reasons we preferred to make the CC-nature of the list apparent in <br>
its generic type, rather than introducing some magic list wrapper which <br>
adds its own special behavior (see Collections::unmodifiableList).<br>
<br>
Now, with that said, I can see this going both ways - while List<CC> is <br>
a more explicit and "honest" representation - what you say re. interop <br>
with clients accepting just a List<V> is also a valid point (and you <br>
can't fully get to a List<V> just by using a Steam mapper, as the <br>
terminal operation `asList` would force eager computation of all the <br>
constants).<br>
<br>
Maurizio<br>
<br>
On 28/08/2023 09:31, - wrote:<br>
> Hello Per and Leyden subscribers,<br>
> First, I am glad that we are finally adding an API that exposes one of <br>
> core libraries' favorite feature, `@Stable`, to common users!<br>
><br>
> For the API design, however, I have a request: Can we have a <br>
> ComputedConstant factory that creates a List<V> in addition to one <br>
> that creates a List<ComputedConstant<V>>?<br>
><br>
> I think using the List<ComputedConstant<V>> is confusing. The example <br>
> usages in the JEP [1] and in the API specification [2] are already <br>
> wrong: we need an extra ConputedConstant.get() call to unwrap the <br>
> ComputedConstant after List.get(index) call, which currently returns a <br>
> computed constant than the actual value.<br>
><br>
> The current List<ComputedConstant<V>> is to be kept in case users want <br>
> fine-grained control over each constant's resolution failure, etc. and <br>
> covers the new factory's functionality. But I believe the new factory <br>
> will see wider usage:<br>
><br>
> 1. None of the 2 old patterns in the "Motivation" section uses any of <br>
> these exception handling or initialization state detection.<br>
> 2. Returning a List<V> allows users to conveniently pass the list in <br>
> usages instead of using streams or writing custom wrappers.<br>
><br>
> A follow up to a previous request [3], I believe having a map (of type <br>
> Map<K, V> instead of Map<K, ComputedConstant<V>>) would be feasible too.<br>
><br>
> Finally, a side comment about the current <br>
> OnDemandComputedConstantList: it computes ComputedConstant wrappers in <br>
> addition to the actual constants on demand, which... seems a bit <br>
> overkill, when ComputedConstant itself is already a lightweight <br>
> wrapper of a heavy computation?<br>
><br>
> Best,<br>
> Chen Liang<br>
><br>
> [1]: <a href="https://openjdk.org/jeps/8312611" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8312611</a>  "var kbd = lbl.labels.get(3);"<br>
> [2]: <br>
> <a href="https://cr.openjdk.org/~pminborg/computed-constant/api/java.base/java/lang/ComputedConstant.html#of(int,java.util.function.IntFunction)" rel="noreferrer" target="_blank">https://cr.openjdk.org/~pminborg/computed-constant/api/java.base/java/lang/ComputedConstant.html#of(int,java.util.function.IntFunction)</a> <br>
>  "return PO2_CACHE.get(n);"<br>
> [3]: <a href="https://mail.openjdk.org/pipermail/leyden-dev/2023-August/000277.html" rel="noreferrer" target="_blank">https://mail.openjdk.org/pipermail/leyden-dev/2023-August/000277.html</a></font><br>
</blockquote></div></div>