Five Buckets/JCrete

[Cay Horstmann]

As a possibly meaningless datapoint, I just presented the design from 
https://mail.openjdk.org/pipermail/valhalla-spec-observers/2022-June/002000.html 
at JCrete. Audience reaction:

1. "References have identity, values don't" is clean and easy to understand
2. T.ref, T.val were non-controversial.
3. Everyone expected/preferred values to be tearable and 
zero-initialized by default
4. Everyone absolutely hated the concept of non-public .val, and much 
groaning occurred when I showed

public value record Complex(double real, double imag) {
      public non-atomic value companion Complex.val;
}

Of course people took potshots at package-private or protected .val types.

People wondered why the five buckets couldn't just be identity + 
value[atomic={yes,no}, zero-default={yes,no}], with some reasonable 
choice of modifiers. I wasn't sure, and we all missed Rémi.

5. Some audience members forcefully demanded guarantees about 
flattening. "If I go through the trouble and make this type a non-atomic 
zero-default value and have an array with a million of them, I want to 
know for sure there are no object headers."

Cheers,

Cay

Il 14/07/2022 21:14, Kevin Bourrillion ha scritto:
> On Wed, Jul 13, 2022 at 1:24 PM John Rose <john.r.rose at oracle.com 
> <mailto:john.r.rose at oracle.com>> wrote:
> 
>       * ...
>       * |Object::getClass| returns a predictable ref-mirror (I always
>         wanted that)
> 
> (aside: Yes, although in the case of `Foo.val value = ...; 
> value.getClass()`, I'll still claim it shouldn't compile or should at 
> least throw, so the user will write whichever of `Foo.class` or 
> `Foo.val.class` they actually want.
> 
>     The surprising outcome of this is we now have (by my count) five
>     buckets.
> 
> Sounds alarming, but mostly we just have to ensure that the individual 
> levers ("value", "non-atomic", visibility) are fully understandable 
> individually and orthogonally, with their combinations acting as 
> expected from that understanding. So long as we achieve that, the 
> tallied up number (5 or 7 or...) doesn't matter as much.
> 
> -- 
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com 
> <mailto:kevinb at google.com>

-- 

Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com