User model stacking: current status

[Brian Goetz]

All fair.  So what this comes down to is whether the uniformity of "ref 
types are all the same" is one that we want to have trumped by 
"non-atomic classes tear in all conditions."  Truly a battle for 
conceptual supremacy.

On 6/15/2022 2:10 PM, Kevin Bourrillion wrote:
> On Wed, Jun 15, 2022 at 10:51 AM Brian Goetz <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. |kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220615/0ab7d09e/attachment.htm>