Computed Constants API question

[-]

Thanks Maurizio,
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.

I think the OnDemandComputedConstantList implementation is unnecessary; we
can just create an array of non-null ComputedConstant elements like:

ComputedConstant<T>[] array = new ComputedConstant<?>[size]; // unchecked
for (int i = 0; i < size; i++) {
    final int t = i;
    array[i] = of(() -> provider.apply(t));
}
return JUCA.listFromTrustedArray(array);

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.

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.

Chen Liang

On Mon, Aug 28, 2023 at 5:29 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230828/fad5f2b7/attachment.htm>