where are all the objects?

Fri Jul 22 17:17:44 UTC 2022

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).

On Tue Jul 19 15:28:27 UTC 2022 Robbe Pincket wrote:

> On Wed Jul 13 20:54:43 UTC 2022, John Rose wrote:
>
> > I’m using a more neutral term "realize" instead of "instantiate".
>
> I'm not really a fan of the term, I see why "instantiate" doesn't fit,
> but I hope stuff will be able to get reworded in such a way that
> "realize" isn't needed.
>
>
> > These propositions seem to be all true (“at least” in part):
> > - The result of realizing at least some classes in some types is, in
fact,
> >   an "object".
> > - The result of realizing at least some classes in some types is, in
fact,
> >   an "instance" of that class.
> > - The result of realizing at least some classes in a value type is a
"value"
> >   of that class.
> > - Every variable "has a value".
> > - Every reference, other than `null`, "refers to an object".
> > - Every non-reference variable “contains a value” (as well as having
it).
>
> I'm very confused what you mean with your last point. "Every
> non-reference variable “contains a value” (as well as having it)". A
> variable is a typed storage location, a variable containing a value or
> a variable having a value are in my mind synonyms. But if I read your
> point, it sounds like you disagree and a non-reference (primitive?)
> variable has and contains 2 (different?) values?
>
>
> ---
>
> On Thu Jul 14 16:48:00 UTC 2022, Kevin Bourrillion wrote:
>
> > The instances of a value type are "values".  The instances of a
> > reference type are "references to objects".  [...] 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).
>
> Oh god, no no no no no nooo. The instances of a reference type are the
> objects, not the references to those objects. The references are the
> values that a variable of a compatible type can hold.

I love your reaction. :-) You're right, I fat-fingered this. What I
*actually* think
is written out in
https://docs.google.com/document/d/1J-a_K87P-R3TscD4uW2Qsbt5BlBR_7uX_BekwJ5BLSE/edit

and I believe it agrees with you completely.

(I do worry I'm being insufferable by plugging these documents I wrote over
and over
on this list, but this experience here provides a good example of why I do
it: they
are more likely to represent what I actually think that whatever email I
clack out one
day to the next. Still, the docs have bugs too, which I'd love to hear
about as well.)

> And no one calls
> primitive values instances, is cause they aren't. All mentions of
> "instances" in Java spec refer to "class instances" or "instances of
> a/the class" (at least as far I can see).

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.

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".

> > An object                      | A value
> > -----------------------------  |
-----------------------------------------
> > has independent existence      | is ephemeral (no existence of its
*own*)
> > is self-describing             | is context-described
> > is accessed via reference      | is used directly
> > is eligible to have identity   | can’t have identity
> > is polymorphic                 | is strictly monomorphic
> > has the type `Object`          | does not have the type `Object`
>
> I agree with some of these but I have a few issues:
> * I feel like independent existence and identity are the same thing,
>   how would you be able to differentiate 2 equal objects that don't
>   have identity?

Perfect question. I think both schools of thought are viable:

* Independent existence requires addressability and addressiblity IS
identity. So, all objects (or "heap objects") have identity, but some
*hide* it from the user
* It is just cleaner to treat "hiding identity" as not having it (but still
having addressability)

I can go into the reasons I like the second at length if necessary.

Weird analogy alert, but I can grab and use a "tablespoon of milk" when I
need to, even though it clearly has no identity.

> * I think I understand what you mean with "self-describing", if I
>   have an object, I expect to be able to call `.getClass`. As a
>   result an object holds all the info to fully interpret the object.
>   But I'm missing something with "context-described". It feels like
>   you are saying a value needs a context to "exist", but values are
>   ephemeral.  They just exist.

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.

"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.)

For every occurrence of a value in a Java program there is always exogenous
awareness of its static type.

> In the end, I don't think "object" and "value" are mutually exclusive.
> Anything that extends Object is an "object", anything that is
> ephemeral is a "value" and anything that is both is a "value object"
> (identityless object)

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.

> > 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.)
>
> Arrays do have members, all the methods of `Object` are inherited by
> arrays, `clone` being one of them.

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.

> ---
>
> John:
> > Even if we give up on making everything an object, I will still
> > request that we cling to *some* word that can uniformly be applied
> > to the result of realizing *any Java class*. If that word is not
> > "object" I think it is "instance".
>
> Kevin:
> > Yes, I think it is absolutely and usefully "instance".
>
> > 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.
>
> Yeah this a bit of a nuisance. It would be nice to have a term that
> covers both "values" and "instances", because in my mind, and instance
> is something that gets instantiated. Ephemeral values don't get
> instantiated, cause they exist. Which means with my view objects of
> value classes aren't instances (?? this surprised me, but I can't
> convince myself otherwise anymore).

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220722/e7c02c3e/attachment-0001.htm>