Toward Condensers

[Brian Goetz]

>
>
>
>     To your question about classpath keys / module keys, the data
>     model says these are singletons (the double circles.)  In the
>     current (mostly mechanical) mapping of data model to API, for each
>     attribute of these singleton keys, we generate a Stream-bearing
>     method to iterate the attribute values (e.g., modules() and
>     classPath()).  The actual ClassPathKey, being a singleton, is
>     completely uninteresting (its an empty record) so it didn't get a
>     representation in the API.  (You might reasonably characterize
>     this as premature API optimization, and that's a fair discussion.)
>
>
> Thanks for the clarification.
>
> A further question about the classpath handling: in 
> ModelUpdater::addToClassPath are new entries appended or prepended?  I 
> can see reasons why condenser authors might want either behaviour.

The model semantics for multi-valued attributes are (currently) like 
that of LinkedHashSet.  That is, duplicates are not permitted, but order 
reflects the order added.  This seems a reasonable starting point, it 
remains to be seen whether this is enough or whether more is needed here.

> Assuming it appends, if a condenser author desperately wanted to 
> prepend, they could work around it via:
>    ContainerKey[] cp = model.classPath().toArray(ContainerKey[]::new);
>     ModelUpdater updater = model.updater();
>     for ( ContainerKey ck : cp) {
>       updater.removeFromClassPath(ck);
>     }
>     updater.addToClassPath(specialFirstCK);
>     for ( ContainerKey ck : cp) {
>       updater.addToClassPath(ck);
>     }
>
> While we should hold off on convenience apis for now, I can see 
> classpath ordering being an area that needs some experimentation.

Yep, that was the envisioned workaround for more complex ordering: 
bulk-remove and a bulk-re-add in the desired order in a transaction.  
One could imagine conveniences in the updater API for such things, and 
we may get there, but I'm trying to get what we can out of the 
simplicity of the underlying model first.  (In reality, all the API 
methods are conveniences; there are really very few primitive 
operations, because it is really just a fixed set of typed&ordered 
relations, and the mutative methods are really limited to add mapping, 
update mapping, remove mapping.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230804/f57aeb4e/attachment.htm>