where are all the objects?

[Brian Goetz]

>
>
>     Of course something will have to change, and we want that change
>     to feel natural and not pulling the rug out from under user's
>     mental models.
>
>     The change I'm proposing in this model is:
>
>     Instead of values being "primitives and object references", values
>     become "value objects and object references".  A Complex.val is a
>     value.  3+2i still meets all the requirements of values: free
>     floating, no canonical location, no identity, immutable.  It's
>     just a "bigger" value that we could have before. Primitives become
>     value objects.  I think people can understand (and will like) this
>     story.
>
>     Variables and containers are unchanged.
>
>     Objects are instances of classes.  Instances of identity classes
>     remain dependent on references to interact with them; instances of
>     value classes can also be the target of references, *and* are
>     values on their own.  (This is not excessively weird, since
>     "Complex" and "reference to Complex" is like `int` and `int *` in C.)
>
>
> It's a familiar aspect of C that Java quite distinctly distanced 
> itself from!

Agreed, and I do feel a little dirty for making the comparison, as we 
have gotten so far without having to understand the distinction between 
`int` and `int *`.  But only a little dirty, because if you want to 
ignore the difference, you can -- and if you want to understand the 
difference there is a pretty clear foundation for it.

Further, in my defense, we have been playing a kind of interesting trick 
since the beginning.  Arguably, Java has *never* had objects -- only 
object references!  You can't denote "reference to X" in the type 
system; some times are just reference types.  And there is no expression 
whose type is any kind of object; only references to objects.  The dot 
operator does some sort of quantum tunneling to access the object state, 
and bring it back into the program, as if by magic.  The Java 1.0 
version of your question is: where are *any* of the objects?

So you could describe my "VAO" position as "finally, you can touch some 
of the objects" (we always knew they were in there somewhere!) The 
identity objects are still as hidden away as ever, but the value objects 
will come out and play, and in fact the legacy primitives are revealed 
to have been "bare" objects all along!   And the box types were a clunky 
way to say "reference to value object", which we've now declunkified.

Where I see your discomfort is the "a value object can be a value *or* a 
referent, dealer's choice."  That is indeed new and confusing.  My claim 
is that this (a) really describes what is going on, (b) is a clean 
generalization of the primitives-and-references we have now, (c) allows 
the primitives to become real objects, and (d) once you internalize this 
"value or referent" duality, the rest comes along easily.  So maybe I've 
just made my peace with this, because I like the properties it gives me.


>
>     Let's take a look at your essential characteristics of objects again.
>
>      - Objects are entities, they have their own independent
>     existence.  I think this one is a consequence of "objects only can
>     be interacted with through references."  That is, there is a kind
>     of value called "reference to object", and the reference refers to
>     ... an object, which is a thing separate from the reference.
>
>     So, *if* an object is the target of a reference, then yes, it must
>     be an entity that is somewhere else, with its independent
>     existence.  "Thing that is the target of an object reference" is
>     one reasonable definition for "Object", but I don't think it is
>     the only one. What I'm saying is that I think its fair to say an
>     instance of Complex is an object (and further, that saying "its an
>     instance, but not an object", is likely to be more confusing that
>     beneficial.)
>
>
>
> Two possible directions of that confusion:
>
> 1. But why is it not an object? The big problem here, raised by John I 
> think, is "Java is an object-oriented language". Uh oh. That certainly 
> does demand the expansive notion of "object"; I have to concede that 
> point. On the other hand, maybe, Java did then put that theory into 
> practice using terms like "instance member", not "object member". It 
> also created a class called "Object" and attached a bunch of specific 
> ideas to that, only 3.5 of which are really general to all instances.
>
> 2. Okay but then why is it still an instance? Here we'd be asking 
> users to shed some of the baggage they've (incidentally) attached to 
> "instance" in the past, realizing that that baggage actually belonged 
> with "object". What remains with "instance" is the essential stuff: 
> instance members, instance state.

The intuition I think users already have, and which we can double down 
on, is that classes are like templates for stamping out 
objects/instances.  The user declares the class with its name, 
supertypes, members, etc, and then can make many instances from the 
template.  So anything that says "instance, but not object" seems 
needlessly confusing, because it breaks an existing intuition that is 
working fine, for little benefit (that I can see.)

The use of object and instance to mean the same thing has an 
understandable historical context.  In the late 80s/early 90s, object 
orientation was an abstract concept; objects are stateful, independent 
entities that communicate by message passing.  (Kay's objects were more 
like Erlang's actors than Java/C++ classes.)  Java (and other languages) 
interpreted OO through the lens of classes, which have instances.  So 
this is really like "class-oriented-language implements 
object-oriented-language", where we say "class instances are what we 
mean by objects."  But, this is historical path-weaving; objects == 
instances seems like a sleeping dog that should be let lie, because the 
cost of changing perception seems way higher than the value of doing so.

>
>       I think the term for what you are describing is *referent*, and
>     not all objects are referents.
>
>
>
> I agree that "referent" is another reasonable choice of term for what 
> the doc calls "object". I think it beats "heap object". But I think it 
> has serious problems (below).
>
>
>       Here, I say that objects remain self-describing under the
>     "instances are objects" model, but something interesting happens
>     under the hood about *where* the description lives.  If I have a
>     `Complex` in a variable of type `Complex.val`, there is sufficient
>     information *in the container* to know the class of the instance,
>     so the instance doesn't have to carry it with it.  There is an
>     operation for "take a reference of" that can be applied to value
>     objects.  This operation (logically, though this is frequently
>     optimized away) takes that information out of the container and
>     puts it in an object header.  But regardless of whether the
>     typestate is in the container or the object itself, objects are
>     self-describing.
>
>
>
> I think this paragraph is merely asking for a different 
> term/definition from the "self-describing" term I'm using and doesn't 
> say anything deeper than that. Maybe there is a better term. I used 
> "self-describing" partly because I thought it has a healthy existing 
> connotation that the data itself is bloated with all that description. 
> e.g. Java serialized forms are self-describing (setting aside all the 
> ways that description can fail).

OK, I think I see what you're getting at.  I'm focusing on 
"self-describing" as "can it answer the question".  (Today, `int` is 
arguably not self-describing by this description, because you can't ask 
it any questions, though that will change.)  You're taking 
self-describing to mean the cost of stapling an object header to the 
payload.  (Which is implicitly one of those "box and pointer" 
perspectives that John talked about, which on the one hand is useful for 
building intuitions, but on the other can build wrong intuitions.)

>
>      - An object is always accessed by reference.  This is what I'm
>     saying changes; value objects are values. So I think that what you
>     are describing as essential characteristics of objects, are really
>     essential characteristics of *referents of object references*. And
>     I would argue that while this is a well-defined concept, it's not
>     the most important distinction we want to put in the user's face. 
>     Instead, we can say that an instance of Complex can be a value, or
>     it can be a referent, but its the same Complex either way, and the
>     user gets to decide what packaging it wants to put it in.
>
>
>
> I think the key thing to notice about "referent" is that it's a role 
> noun (I don't know what grammarians would call it), like "pedestrian" 
> or "projectile". That is, it doesn't seem to be saying anything at all 
> about the thing itself, only about the role that thing is currently 
> playing in some broader relationship or activity.

Yes!  Which is in line with the fact that we blur the distinction 
between reference and referent today, and we will continue to blur it 
tomorrow.  And whether a value is a value object or an object reference 
is steered by types -- whether the types are value types or reference 
types.  But one reason to push this "its the same instance either way", 
is that it goes a ways towards busting the existing concept of boxing.  
The existing concept of boxing appeals to "construct a new box" and 
"unpack the value from the box", which (a) sounds like a lot of motion 
(it is) and (b) says that the primitive and the box are totally 
different kinds of things. Whereas the "value object vs referent" 
encourages a model of "its the same thing all along, we are just holding 
it differently."  Bare hands vs tongs, if you will.

Are we getting any closer, or just digging in?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220725/0055620b/attachment-0001.htm>