[External] : Re: Consolidating the user model

[Brian Goetz]

I would summarize what you've been on about as "Hey, developers are used 
to primitives and boxes, is there mileage in working within that 
framework, rather than tossing it out the window because boxes seem 
dirty?"  And I think there is something to that.

One way to frame this is that there's a model that makes sense from a 
specification perspective, and there's a mental model that makes sense 
to Java users, and these need not be the same. A prime (wildly 
unrelated) example of this is the "double brace idiom"; language weenies 
cringe because it's not actually a thing, its just an interaction 
between an unfortunate syntax choice for instance initializers and 
otherwise empty anonymous classes, but what does it matter if users 
think it's a thing?

The spec already has opinions about what terms like "value", "object", 
"reference", etc mean.  Internally, we have to respect these (or pay the 
cost to refactor the terminology), but this only weakly constrains the 
user model.  The language spec makes clear distinctions between classes 
and types, but most developers can slush the differences away and spend 
that mental bookkeeping budget elsewhere.  The main risk of trying to 
present an alternate model is that it will invariably use terms (e.g., 
"object") that appear to have their meaning nailed down; perhaps we need 
a notational convention to distinguish between "what the spec currently 
calls object" and "what users understand objects to be", at least for 
sake of discussion?



On 11/4/2021 12:08 PM, Kevin Bourrillion wrote:
> On Thu, Nov 4, 2021 at 7:56 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
>     On 11/4/2021 2:54 AM, Kevin Bourrillion wrote:
>>
>>         Point.ref pr = pv;  // same object… now it’s on the heap,
>>         though, with a real live heap header
>>         assert pr.getClass() == Point.class;  // same class, but...
>>
>>
>>     Why would we even want this? It would be very surprising/puzzling
>>     to me.
>     It's surprising because we're so used to "boxes" being a thing. 
>     But let's look at this a bit.
>
>
> Okay, it's clear I have more work to do in understanding your whole 
> coherent model as it exists.
>
> Summary of what kevinb has been on about the last 24 hours:
>
> The model I've been speaking for over the past day has flowed from 
> following my own "I want to think it's as simple as...." intuitions. I 
> expected to sort of "hit a wall" with those naive assumptions and 
> never felt like I did (yet).
>
> Your model is likely enough the best, and I'm simply "resisting" it, 
> but in that case I'm channeling some of the resistance other users 
> will feel, and we can hash out how to head it off. But also, 
> occasionally I turn out to be right about things so I'll prepare for 
> that misfortune as well.
>
> I think it's worth my understanding both models until I can explain 
> them well, and /then/ we can make more progress. Let's just name the 
> models. Fair enough? (Feel free to inject "no need to name your model 
> because I can give the killer argument right now why it just can't 
> work", I mean we wouldn't name a woodland animal we found moments from 
> death on the side of the road, would we.)
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com