<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">I also feel strongly that we need to accept that *no matter which* way we go, there will be some terminology clarifications we need to make that will rub users the wrong way, where they used to think "X always means Y", and we start telling them
"not anymore". All my work has been toward trying to understand *which* of these breaks are more or less damaging than others and why. It doesn't work to just cite the disadvantages of one particular shift as self-sufficient argument that we shouldn't do it.
It's about pain A vs. pains B/C.</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
Agreed.</div>
<div><br class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">
<div class="">Note that *some* decisions which produce strong initial antipathy in the minds of users will actually become good teachable moments! "Here's why the reaction you had was tied to old assumptions that we are intentionally leaving behind for these
good reasons." Even a user who doesn't <i class="">agree</i> with the decision can still hang their <i class="">learning</i> onto this. In fact I think some of the *best* teachable moments will be like that. But not all such breaks we could make will be so
teachable; some will yield persistent confusion. (This is part of what I meant by "more/less damaging" just above.)</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Yes, sometimes! And sometimes you are just swimming against the tide. And sometimes its hard to know which is which :(</div>
<br class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">
<div class="">"My way" (i.e. that I've been advocating thus for) might not be the right way in the end, but I've not gotten as clear of an understanding of the alternative. Brian, I think you declined *twice* on this thread to answer my question of what you
would call the thing that I've precisely called "object" (once being off-list (my bad)). John finally volunteered (also off-list (my bad)) "heap object"; okay then, that at least lets us put together a more complete picture that we can evaluate the pros and
cons of.</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Sorry, I think I misunderstood, and answered “what do you call an object”. So let’s circle back: give me your object definition again so I don’t mis-answer again, and I’ll try to come up with a name for it?</div>
<br class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">So then, would we call an instance of `Complex.val` a "non-heap object" or an "inlined object" or what? We need to flesh out a whole lexicon. The phrase "value object" becomes useless for this particular distinction as it will apply to both.</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Yes, in the taxonomy I’m pushing, a “value object” is one without identity, and is the kind of object you can store directly in variables without going through a reference. But I don’t think that there are instances of Complex.val and instances of Complex.ref;
I think there are instances of *Complex*, and multiple ways to describe/store/access them. </div>
<br class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">Users don't always have a stable and precisely developed vocabulary (I sure didn't until I had to work all this stuff through for this group), but what we do have, deeply, is our years of experience understanding
<i class="">the difference between int and Integer</i> and how to make that choice in our code.
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Right. Though, the difference we historically have (Integer is an identity class that happens to contain a sole int field) is full of accidental detail (accidental identity, ad-hoc boxing and unboxing conversions with magic methods like valueOf, etc)
and what we might want to describe this difference as. </div>
<div><br class="">
</div>
<div>The mental model I’ve had for some time, and which is where .val and .ref come from, is that there are abstract things called Complex, and you can pass/store a Complex by value, or by reference. The value/reference distinction has meaning from before
the days of Java. We papered over the difference historically by not letting you touch the objects, but always requiring an intermediary (a reference), and *that* is what is changing now. </div>
<br class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">(There's a principle in here somewhere that oughtta be stated in some better way than this: users will know the distinctions between concepts if those are the distinctions that have actively driven the
<i class="">decisions</i> those users have had to make, and not as much otherwise.)</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>See previous !</div>
<br class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<blockquote style="margin:0 0 0 40px;border:none;padding:0px" class="">
<div class=""><br class="">
That `int/Integer` decision you've been making has always been between (1) value and (2) (reference-to) object, and that decision is
<i class="">still</i> exactly between (1) value and (2) (reference-to) object now, and btw the definitions of 'reference' and 'object' remain precisely wedded to each other as always.</div>
<div class=""><br class="">
</div>
</blockquote>
<div class="">The "heap object" alternative strikes me (and I am <i class="">trying</i> to be fair, here) as:</div>
<div class=""><br class="">
</div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px" class="">
<div class="">Now, that's an object either way, and you're going to apply that old thought process toward which *kind* of object you mean, either a (1) "inline object" or a (2) "(reference-to) heap object". It's now just heap objects and references that are
paired together.</div>
</blockquote>
<div class="">
<div class=""><br class="">
</div>
<div class="">Starting to prefer the first way (as I did) did not feel like going rogue: after all, did we not gravitate toward ".ref" and ".val" as our placeholder syntaxes, not ".inline" and ".heap" or anything else?</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
With you on this. I think asking users to reason about “heap objects” vs “inline objects” is pushing them towards the implementation, not the concepts. They may have to reason about this to understand the performance model, but that’s already advanced material.
</div>
<div><br class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">
<div class=""><br class="">
</div>
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jul 22, 2022 at 8:18 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" class="">brian.goetz@oracle.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
FWIW, this was the intuition I was leaning into: <br class="">
<br class="">
> We're trying to make a distinction between primitive values being "class instances" and calling them "objects", but for many developers, especially beginners, that sounds like meaningless pedantry. We might be over-rotating on the subtle differences that
make these entities distinct, rather than acknowledging that, with their fields and methods, they will be commonly understood to be a kind of object.”<br class="">
<br class="">
<br class="">
Making a distinction between object and instance is likely to be confusing and irritating to users. So I was leaning into preserving these common intuitions:
<br class="">
<br class="">
- users declare classes<br class="">
- classes have instances<br class="">
- instances are objects<br class="">
- objects/instances know what class they are <br class="">
<br class="">
And extending them to “and now, the primitives are objects/instances too” (which I think is an evolution people will like, because it moves us towards “everything is an object.”).
<br class="">
<br class="">
The new bit, which is the cost of all this, is that for at least id-free objects, there are TWO ways to put them in a variable: put the object itself in a variable, or put a reference to the object in a variable. This is a tricky new concept, but it is consistent
with the companion-types model: the value set of C.val are the instances of C; the value set of C.ref are *references to* the instances of C.
<br class="">
<br class="">
<br class="">
</blockquote>
</div>
<br clear="all" class="">
<div class=""><br class="">
</div>
-- <br class="">
<div dir="ltr" class="gmail_signature">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif" class="">
<span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px" class="">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px" class=""> Java
Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px" class=""> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px" class=""> <a href="mailto:kevinb@google.com" target="_blank" class="">kevinb@google.com</a></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>