Reader mail bag

[Brian Goetz]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230601/86f2965d/attachment-0001.htm>