<div dir="ltr"><div>Here's a worthy reply that appeared on -observers -- I'll quote it in full and intersperse my own responses (hopefully that's an okay protocol).</div><div><div><br></div><div><br></div><div>On Tue Jul 19 15:28:27 UTC 2022 Robbe Pincket wrote:</div></div><div><br></div><div><font face="monospace">> On Wed Jul 13 20:54:43 UTC 2022, John Rose wrote:<br>><br>> > I’m using a more neutral term "realize" instead of "instantiate".<br>><br>> I'm not really a fan of the term, I see why "instantiate" doesn't fit,<br>> but I hope stuff will be able to get reworded in such a way that<br>> "realize" isn't needed.<br>><br>><br>> > These propositions seem to be all true (“at least” in part):</font></div><div><font face="monospace">> > - The result of realizing at least some classes in some types is, in fact,<br>> >   an "object".</font></div><div><font face="monospace">> > - The result of realizing at least some classes in some types is, in fact,</font></div><div><font face="monospace">> >   an "instance" of that class.</font></div><div><font face="monospace">> > - The result of realizing at least some classes in a value type is a "value"<br>> >   of that class.</font></div><div><font face="monospace">> > - Every variable "has a value".</font></div><div><font face="monospace">> > - Every reference, other than `null`, "refers to an object".</font></div><div><font face="monospace">> > - Every non-reference variable “contains a value” (as well as having it).<br>><br>> I'm very confused what you mean with your last point. "Every<br>> non-reference variable “contains a value” (as well as having it)". A<br>> variable is a typed storage location, a variable containing a value or<br>> a variable having a value are in my mind synonyms. But if I read your<br>> point, it sounds like you disagree and a non-reference (primitive?)<br>> variable has and contains 2 (different?) values?<br>><br>><br>> ---<br>><br>> On Thu Jul 14 16:48:00 UTC 2022, Kevin Bourrillion wrote:<br>><br>> > The instances of a value type are "values".  The instances of a<br>> > reference type are "references to objects".  [...] But primitive<br>> > values are instances too. Of primitive types. I think that has<br>> > always been true (though most of us aren't in the habit of saying<br>> > it, because they were never *class instances* which is a very useful<br>> > kind).<br>><br>> Oh god, no no no no no nooo. The instances of a reference type are the<br>> objects, not the references to those objects. The references are the<br>> values that a variable of a compatible type can hold.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">I love your reaction. :-) You're right, I fat-fingered this. What I *actually* think</font></div><div><font face="monospace">is written out in </font></div><div><span style="font-family:monospace"><a href="https://docs.google.com/document/d/1J-a_K87P-R3TscD4uW2Qsbt5BlBR_7uX_BekwJ5BLSE/edit">https://docs.google.com/document/d/1J-a_K87P-R3TscD4uW2Qsbt5BlBR_7uX_BekwJ5BLSE/edit</a> </span></div><div><font face="monospace">and I believe it agrees with you completely.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">(I do worry I'm being insufferable by plugging these documents I wrote over and over</font></div><div><font face="monospace">on this list, but this experience here provides a good example of why I do it: they</font></div><div><font face="monospace">are more likely </font><span style="font-family:monospace">to represent what I actually think that whatever email I clack out one</span></div><div><span style="font-family:monospace">day to the next. </span><span style="font-family:monospace">Still, the docs have bugs too, which I'd love to hear about as well.)</span></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace">> And no one calls<br>> primitive values instances, is cause they aren't. All mentions of<br>> "instances" in Java spec refer to "class instances" or "instances of<br>> a/the class" (at least as far I can see).</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">Because "instance" is usually assumed to mean "instance of a class", then yes, primitive values never have been instances, but interestingly we are going to make them instances.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">As "instances of a type", I need to think more about what I am trying to accomplish with that term, as I have myself just confused it with "values of the type".</font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br>> > An object                      | A value<br>> > -----------------------------  | -----------------------------------------<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>><br>> I agree with some of these but I have a few issues:<br>> * I feel like independent existence and identity are the same thing,<br>>   how would you be able to differentiate 2 equal objects that don't<br>>   have identity?</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">Perfect question. I think both schools of thought are viable:</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">* Independent existence requires addressability and addressiblity IS identity. So, all objects (or "heap objects") have identity, but some *hide* it from the user</font></div><div><font face="monospace">* It is just cleaner to treat "hiding identity" as not having it (but still having addressability)</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">I can go into the reasons I like the second at length if necessary.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">Weird analogy alert, but I can grab and use a "tablespoon of milk" when I need to, even though it clearly has no identity.</font></div><div><br></div><div><font face="monospace"><br>> * I think I understand what you mean with "self-describing", if I<br>>   have an object, I expect to be able to call `.getClass`. As a<br>>   result an object holds all the info to fully interpret the object.<br>>   But I'm missing something with "context-described". It feels like<br>>   you are saying a value needs a context to "exist", but values are<br>>   ephemeral.  They just exist.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">Yes, objects are self-describing because they have a dynamic type and, in the array case, a length. The thing itself contains sufficient information to find out how it is laid out in memory.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">"Value" does have a Platonic meaning, like "the value 42" which transcends time and space. I'm not invoking that particular meaning. I'm talking about one "occurrence" of that value inside a running program (but still at a conceptual-model level, above things like registers). In carrying out "a = b + 5", something is "told" to the + expression by (a) a variable read and (b) a literal expression, and then it "tells" something else to the assignment expression. Those somethings are values. I would use the word "message" if it wasn't so overloaded in computing already with other meanings. (Some of my words may make values sound like countable "things" but it's unproductive to think that way.)</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">For every occurrence of a value in a Java program there is always exogenous awareness of its static type.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br>> In the end, I don't think "object" and "value" are mutually exclusive.<br>> Anything that extends Object is an "object", anything that is<br>> ephemeral is a "value" and anything that is both is a "value object"<br>> (identityless object)</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">I have also accepted the term "value object" for things like `Complex.ref`, grudgingly, but I still insist that *a value object is not a value*. It's an object that is value-like or value-based. The viewpoint in the linked document does maintain that "value" and "object" are disjoint, and I think that is a splendid thing.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br>> > I would say that arrays are also instances -- of array types. What<br>> > they aren't is *class* instances. (So they don't get to have<br>> > members; `length` and `clone` are at best half-heartedly-simulated<br>> > members.)<br>><br>> Arrays do have members, all the methods of `Object` are inherited by<br>> arrays, `clone` being one of them.</font></div><div><br></div><div>Yes, "arrays don't get to have members" is a simplified description of a weird reality. An array type gets the Object type as its supertype, and inherits the type members thereof. That doesn't explain the *public* `clone()` method or `length` pseudo-field, which both arise out of some invisible magic that reflection won't even cop to.</div><div><font face="monospace"><br></font></div><div><font face="monospace"><br>> ---<br>><br>> John:<br>> > Even if we give up on making everything an object, I will still<br>> > request that we cling to *some* word that can uniformly be applied<br>> > to the result of realizing *any Java class*. If that word is not<br>> > "object" I think it is "instance".<br>><br>> Kevin:<br>> > Yes, I think it is absolutely and usefully "instance".<br>><br>> > A tough spot about my model (which I think is<br>> > unavoidable/acceptable) is that I can't get away with saying "An<br>> > object is any class instance or array" anymore.<br>><br>> Yeah this a bit of a nuisance. It would be nice to have a term that<br>> covers both "values" and "instances", because in my mind, and instance<br>> is something that gets instantiated. Ephemeral values don't get<br>> instantiated, cause they exist. Which means with my view objects of<br>> value classes aren't instances (?? this surprised me, but I can't<br>> convince myself otherwise anymore).</font></div><div><font face="monospace"><br></font></div><div><font face="monospace">I do think "instantiate" often carries a connotation of bringing something into existence that never existed otherwise, but I'm not sure it *should* have that connotation. For example `List<String>` is often called a "type instantiation" of `List<E>`" but nothing was birthed into the world by writing that; it was just sort of obtained from the ether.</font></div><div><font face="monospace"><br></font></div><div><font face="monospace"><br></font></div></div>