<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:CAJq4Gi6i1jxZ8eqVX2arvVaTkApo6AMWiFquGSAm43_qbrM7XA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> <br>
<br>
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.)<br>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks for the clarification.</div>
<div><br>
</div>
<div>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. <br>
</div>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
<blockquote type="cite" cite="mid:CAJq4Gi6i1jxZ8eqVX2arvVaTkApo6AMWiFquGSAm43_qbrM7XA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>Assuming it appends, if a condenser author desperately
wanted to prepend, they could work around it via:</div>
<div> ContainerKey[] cp =
model.classPath().toArray(ContainerKey[]::new);</div>
<div> ModelUpdater updater = model.updater();</div>
<div> for ( ContainerKey ck : cp) {</div>
<div> updater.removeFromClassPath(ck);</div>
<div> }</div>
<div> updater.addToClassPath(specialFirstCK);</div>
<div>
<div> for ( ContainerKey ck : cp) {</div>
<div> updater.addToClassPath(ck);</div>
<div> }</div>
<div><br>
</div>
<div>While we should hold off on convenience apis for now, I
can see classpath ordering being an area that needs some
experimentation.</div>
</div>
</div>
</div>
</blockquote>
<br>
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.) <br>
<br>
</body>
</html>