<div dir="ltr"><div>You knew you could count on me. :-)</div><div><br></div><div><br></div><div dir="ltr">On Wed, Jul 13, 2022 at 1:54 PM John Rose <<a href="mailto:john.r.rose@oracle.com">john.r.rose@oracle.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 13 Jul 2022, at 13:23, John Rose wrote:</p>
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<p dir="auto">…Another result of backing away from “primitive” is that we have to engage with the question of “where are the objects?” Obviously every non-null value of a variable whose type is an identity class refers to “an object”. But beyond that it gets dicey and we will have to adjust our agreements, I think. This is probably worth a separate thread, which I will start, and which I expect Kevin will be very interested in.</p>
</blockquote>
<p dir="auto">A class defines ways to “realize” the class in its types, that is, in variables of its companion types.</p></div></div></div></blockquote><div>Aside: I'd push back on the term "companion types of a class"; the class *defined* those types so they are just its "defined types".</div><div><br></div><div>I do like calling the value type a "companion type to the reference type" (not to the class) well enough, though. For a couple reasons -- there is the parallel relationship of equals that I expect "companions" to have, and it's injecting a new term for a new concept, which is easier for folks to swallow than "we need a new term for an old concept while we are simultaneously injecting new concepts too".</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Examples: <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C r = new C();</code> and <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C.val v = C.default;</code> and <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">new C.val[1]</code>.</p>
<p dir="auto">(For class declared non-atomic, races can also “realize” values of the class.)</p>
<p dir="auto">I’m using a more neutral term “realize” instead of “instantiate”. You can think “instantiate” or “construct” if you like. A long-winded way to say “realize a class” without tripping over words I want to avoid is “make a non-<code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">null</code> runtime configuration of a variable of a type of that class, using, directly or indirectly, an expression allowed by the declaration of that class”.</p></div></div></div></blockquote><div>Fair enough; I'm viewing this roughly as "originating (summoning, conjuring) an instance of the type", as distinct from "being handed it from somewhere".</div><div><br></div><div>I think we are more precisely talking about "realizing the <i>type</i>", and "realizing the class" is a shorthand for "realizing one of the types defined by the class". It seems too ambiguous to focus on "realizing the class".</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">These propositions seem to be all true (“at least” in part):</p>
<ul>
<li>The result of realizing at least some classes in some types is, in fact, an “object”.</li>
<li>The result of realizing at least some classes in some types is, in fact, an “instance” of that class.</li>
<li>The result of realizing at least some classes in a value type is a “value” of that class.</li></ul></div></div></div></blockquote><div>My model sees this instead as:</div><div><br></div><div>The instances of a value type are "values".</div><div>The instances of a reference type are "references to objects".</div><div>The result of realizing a type will always be an instance of that type by definition.</div><div>The "instances of a class" is a slightly more problematic phrase I'd rather avoid. </div><div><br></div><div>(Of course, I say this to suggest that I think the differences are important.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><ul>
<li>Every variable “has a value”.</li>
<li>Every reference, other than <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">null</code>, “refers to an object”.</li></ul></div></div></div></blockquote><div>(imho we would do well to shift to "null <i>isn't</i> a reference, but the lack of a reference where a reference could be". It lacks the most basic and important capability all references have: the ability to be dereferenced. But I understand that may be a big change, and not necessarily supported by theory.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><ul>
<li>Every non-reference variable “contains a value” (as well as having it).</li></ul></div></div></div></blockquote><div>Fair enough. I won't go into the subtle reasons why I use "remembers a value" over "contains a value".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><ul>
</ul>
<p dir="auto">So, do we think they are true? And of which classes, and for which of their companion types, are they true?</p>
<p dir="auto">I think some of us would like to reserve the term “object” for something that has a header and a storage block in the heap. Although talking about memory blocks and headers and machine pointers is probably illegitimate for a JVMS, it is semi-transparent enough to “see” that stuff like that is going on. (Except when it isn’t: Both Valhalla flattened references and classic escape analysis break those intuitions.) Users will want <em>something</em> to visualize about objects, and maybe that just doesn’t jibe with how we want them to think about values.</p></div></div></div></blockquote><div>Heh, yes, I've been pretty determined about this. I see a beautifully clean distinction between objects and values, that I would feel grief at losing:</div><div><br></div><div><div><font face="monospace">An object A value</font></div><div><font face="monospace">----------------------------- -----------------------------------------<br>has independent existence is ephemeral (no existence of its *own*)<br>is self-describing is context-described<br>is accessed via reference is used directly<br>is eligible to have identity can’t have identity<br>is polymorphic is strictly monomorphic<br>has the type `Object` does not have the type `Object`<br></font><br></div></div><div>If we let values of value types (i.e., all values except references and null) become "objects" too, then we will need a term for what used to mean "object" above. For me it is hard to see that ending up in a smooth and shiny place.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">OTOH, it is really freeing to be able to say that “every class makes objects”, and build from there into a world of “identity objects” and “value objects”.</p></div></div></div></blockquote><div>But, in this lexicon, "value objects" becomes ambiguous between (what we'd been calling) bucket 2 and bucket 3.</div><div><br></div><div>In the model I've been advocating we have: "the instances of identity classes are identity objects; the instances of value classes are either value objects or just (composite) values." This brought me rare feelings of terminological victory, the kind of clarity you hope to be able to achieve but almost never can. Granted, it's still got to be carefully taught to everyone, against some amount of resistance, but that's true no matter what lexicon we adopt. Some old associations will <i>have</i> to be broken.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">(I can also appeal to various C standards, in which everything is either an object or a function. Yes, a C <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">int</code> is a C object. Take that, Mr. Objects-Are-Everywhere Java. That might work for us too with minor adjustments.)</p>
<p>Even if we give up on making everything an object, I will still request that we cling to <em>some</em> word that can uniformly be applied to the result of realizing <em>any Java class</em>. If that word is not “object” I think it is “instance”.</p></div></div></div></blockquote><div>Yes, I think it is absolutely and usefully "instance".</div><div><br></div><div>And all instances except arrays (ugh, let's dodge whether null is an instance) are more specifically *class instances*, and that's what gives us instance members. I believe *that* is the unification we've really been driving for when we've said words like "we want to make everything an object".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Also I think it is still useful to at least pretend (virtually) that a reference is always to an object. So, something like this:</p>
<ul>
<li>
<p dir="auto">The result of realizing any class in its reference companion is an object of that class.</p>
</li>
<li>
<p dir="auto">The result of realizing any class into any of its companion types is an instance of that class.</p>
</li>
<li>
<p dir="auto">The result of realizing any value class into its value companion is a “value” of that class.</p>
</li>
<li>
<p dir="auto">Maybe also: The result of realizing any value class into its reference companion is a “value” of that class (as well a an “object” of that class).</p></li></ul></div></div></div></blockquote><div>I would say no to this: a "value object" is not a "value". That takes explaining/apologetics, of course, so I don't love the term "value object" for that reason, but have no *other* complaint about it and can live with it. "identityless object" is just too unwieldy.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><ul>
<li>
<p dir="auto">Every variable “has a value”. (Same as above.)</p>
</li>
<li>
<p dir="auto">Every reference, other than <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">null</code>, “refers to an object”. (Same as above.)</p>
</li>
<li>
<p dir="auto">Every non-reference variable “contains a primitive” or “contains an instance”.</p></li></ul></div></div></div></blockquote><div>But primitive values are instances too. Of primitive types. I think that has always been true (though most of us aren't in the habit of saying it, because they were never *class instances* which is a very useful kind). Soon it will be "even more true" as they also even become *class* instances.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><ul>
<li>
<p dir="auto">Any value is (therefore) either a primitive, an instance, a <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">null</code> reference, or a reference to an object.</p></li></ul></div></div></div></blockquote><div>I think "instance" is awkwardly standing in for something more specific, here. I think I'd say "a value is either an instance of a value type (such as a primitive type), a reference to an object, or the null reference".</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><ul>
<li>
<p dir="auto">An object (therefore) is an instance or an array. (Cribbing from Kevin here.)</p></li></ul></div></div></div></blockquote><div>I would say that arrays are also instances -- of array types. What they aren't is *class* instances. (So they don't get to have members; `length` and `clone` are at best half-heartedly-simulated members.)</div><div><br></div><div>A tough spot about my model (which I think is unavoidable/acceptable) is that I can't get away with saying "An object is any class instance or array" anymore. Because Long is a class, it defines two types, and both those types have instances, and all those instances deserve equally to be considered "instances of the class". So the term "class instance" becomes inclusive of `(int) 42` which is so not an object.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><ul>
<li>
<p dir="auto">By an abuse of language, it is common to ignore the reference part of a reference variable, and say that it “has” or “contains” an instance if not <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">null</code>. (This makes opportunities for consistent reasoning about <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C.ref</code> and <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C.val</code> variables.)</p></li></ul></div></div></div></blockquote><div>Yeah, since the language and runtime abstract references away from us, traversing them for us when needed, we naturally also abstract them away from our speech and thoughts much of the time. I'm okay with "has an instance" but "contains an instance" is the kind of phrase I'd gently push back on, because it's tantamount to "the instance is contained by".</div><div><br></div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">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"> 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"> 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"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div></div>