Some comments received on the -comments list over the past month or so:
-
https://mail.openjdk.org/pipermail/valhalla-spec-comments/2023-June/000049.html
(Quan Mai)
-
https://mail.openjdk.org/pipermail/valhalla-spec-comments/2023-April/000048.html
(Dmitry Paltatzidis)
-
https://mail.openjdk.org/pipermail/valhalla-spec-comments/2023-April/000047.html
(Victor Nazarov)
Victor N proposes "having immediate default" for B3 classes. This is
nicely evocative, but a bit long; we seem to be converging on
"implicitly constructible" for this term. Also "immediate" is a term
that is better known to assembly language programmers; "constructor" is
a term in the Java developer's lexicon.
Dmitry P reiterates some concerns about how users will be tempted to
overuse B3 "because performance", and end up creating less safe programs
as a result. He raises two examples, Rational and Range.
Rational is unfortunate because the default representation (when used
improperly) can lead to DBZE, but has a sensible default of zero --
except for that pesky denominator. However, I think this is a removable
discontinuity, where the author can make up for this with some careful
coding:
value class Rational {
private int n, d;
// obvious explicit and implicit ctor
public int num() { return n; }
public int denom() { return d == 0 ? 1 : 0; }
// logic uses num() and denom() rather than n/d
}
The moral of the story here is that sometimes class authors will have to
do some extra work to interpret the default representation as meaning
"what it should" if they want to take advantage of the benefits of B3,
but all of this can be encapsulated to the implementation.
The other moral hazard Dmitry P raises is the temptation to expose a
Range class that tears, "because performance". Indeed, Java developers
frequently write and publish broken code "because performance", and we
can't stop them -- all we can do is educate them. It is a valid fear
that people will over-rotate towards the new shiny rocket fuel, and in
fact quite likely that people will do so initially. We will have to use
the levers we have -- education, good examples, sufficiently scary
"don't be this guy" responses on Reddit and SO, IDE inspections, etc.
Quan M raises the concern that ! opts into both non-nullity and, for
non-atomic B3 classes, non-atomicity, and wonders whether there should
be an explicit use-site syntax for non-atomicity.
The answer to this is an emphatic "no". I direct readers to the posting
"On atomicity and tearing"; non-atomicity is not a feature to be
programmed with directly, as much as a way of trading off one bad
consequence vs another in the presence of broken programs.
