<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Some comments received on the
-comments list over the past month or so: <br>
<br>
-
<a class="moz-txt-link-freetext" href="https://mail.openjdk.org/pipermail/valhalla-spec-comments/2023-June/000049.html">https://mail.openjdk.org/pipermail/valhalla-spec-comments/2023-June/000049.html</a>
(Quan Mai)<br>
-
<a class="moz-txt-link-freetext" href="https://mail.openjdk.org/pipermail/valhalla-spec-comments/2023-April/000048.html">https://mail.openjdk.org/pipermail/valhalla-spec-comments/2023-April/000048.html</a>
(Dmitry Paltatzidis)<br>
-
<a class="moz-txt-link-freetext" href="https://mail.openjdk.org/pipermail/valhalla-spec-comments/2023-April/000047.html">https://mail.openjdk.org/pipermail/valhalla-spec-comments/2023-April/000047.html</a>
(Victor Nazarov)<br>
<br>
<br>
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. <br>
<br>
<br>
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. <br>
<br>
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:<br>
<br>
value class Rational { <br>
private int n, d;<br>
<br>
// obvious explicit and implicit ctor<br>
<br>
public int num() { return n; }<br>
public int denom() { return d == 0 ? 1 : 0; }<br>
<br>
// logic uses num() and denom() rather than n/d<br>
}<br>
<br>
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.<br>
<br>
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. <br>
<br>
<br>
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.
<br>
<br>
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. <br>
<br>
<br>
</font></font>
</body>
</html>