User model stacking: current status

[Remi Forax]

> From: "Kevin Bourrillion" <kevinb at google.com>
> To: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "daniel smith" <daniel.smith at oracle.com>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Sent: Thursday, June 16, 2022 9:16:43 PM
> Subject: Re: User model stacking: current status

Hi Kevin, 

>> And arrays are much worse.

> Arrays in general, or just the one single construction path `new TheType![size]`
> (or `new TheType.val[size]`)? I would just say please give us new Arrays
> methods or syntax that create and fill at once, and we'll get busy clamping
> down on everything else.

It does work even in simple cases, by example try to write ArrayList or ArrayDeque with that primitive (array + fill). 

Rémi 

>> On 6/15/2022 2:10 PM, Kevin Bourrillion wrote:

>>> On Wed, Jun 15, 2022 at 10:51 AM Brian Goetz < [ mailto:brian.goetz at oracle.com |
>>> brian.goetz at oracle.com ] > wrote:

>>>> - If we spelled .val as !, then switching from P[] to P![] not only prohibits
>>>> null elements, but changes the layout and _introduces tearing_. Hiding
>>>> tearability behind "non-null" is likely to be a lifetime subscription to
>>>> Astonishment Digest, since 99.9999 out of 100 Java developers will not be able
>>>> to say "non-null, oh, that also means I sacrifice atomicity."

>>> Well, that's what you opted into when you... wait a minute...

>>>> The link you probably want to attack is this last one, where you are likely to
>>>> say "well, that's what you opted into when you said `non-atomic`; you just
>>>> happen to get atomicity for free with references, but that's a bonus."

>>> Your Kevin's Brain Emulator has gotten pretty decent over time... check whether
>>> the next things it said were these (probably so):

>>> A good clean Basic Conceptual Model For Novices is allowed to have a bunch of
>>> asterisks, of the form "well, in $circumstance, this will be revealed to be
>>> totally false", and that's not always a strike against the model. How do we
>>> discern the difference between a good asterisk and a bad one? How common the
>>> circumstance; how recognizable as being a special circumstance; how
>>> disproportionate a truth discrepancy we're talking about; etc.

>>> I know I've said this before. If I'm in a class being taught how this stuff
>>> works, and the teacher says "Now unsafe concurrent code can break this in
>>> horrible ways, and in $otherClass you will learn what's really going on in the
>>> presence of data races" ... I feel fully satisfied by that. I know I won't get
>>> away with playing fast and loose with The Concurrency Rules; I'm not advanced
>>> enough and might never be. (Many people aren't but don't know it, and therein
>>> lies the problem, but do we really have much power to protect such people from
>>> themselves?)

>>> I could be wrong, but I suspect this kind of viewpoint might be more common and
>>> respected in the wider world than it is among the rarefied kind of individuals
>>> who join expert groups, no offense to anyone here meant. You're always going to
>>> see all the details, and you're always going to want to see all the details.
>>> The general public just hopes the details stay out of their way. When they
>>> don't, they have a bad day, but it doesn't mean they were better served by a
>>> complex model that tried to account for everything.

>>> --
>>> Kevin Bourrillion | Java Librarian | Google, Inc. | [ mailto:kevinb at google.com |
>>> kevinb at google.com ]

> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | [ mailto:kevinb at google.com |
> kevinb at google.com ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20220616/e1e6e7c5/attachment.htm>