<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:CAGKkBkvQesGv7ZtLi_MpC1HKaxMz9uJ4++v=vNzHpCqd92RB_Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><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><font size="4"><font face="monospace"> 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. <br>
<br>
The change I'm proposing in this model is: <br>
<br>
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. <br>
<br>
Variables and containers are unchanged. <br>
<br>
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.)</font></font></div>
</blockquote>
<div><br>
</div>
<div>It's a familiar aspect of C that Java quite distinctly
distanced itself from!</div>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
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? <br>
<br>
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. <br>
<br>
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. <br>
<br>
<br>
<blockquote type="cite" cite="mid:CAGKkBkvQesGv7ZtLi_MpC1HKaxMz9uJ4++v=vNzHpCqd92RB_Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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><font size="4"><font face="monospace">Let's take a look
at your essential characteristics of objects again. <br>
<br>
- 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. <br>
<br>
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.)</font></font></div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Two possible directions of that confusion:</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.) <br>
<br>
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. <br>
<br>
<blockquote type="cite" cite="mid:CAGKkBkvQesGv7ZtLi_MpC1HKaxMz9uJ4++v=vNzHpCqd92RB_Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div><font size="4"><font face="monospace"> I think the
term for what you are describing is *referent*, and
not all objects are referents.</font></font></div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>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).</div>
<div><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><font size="4"><font face="monospace"> 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.</font></font></div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>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).</div>
</div>
</div>
</blockquote>
<br>
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.) <br>
<br>
<blockquote type="cite" cite="mid:CAGKkBkvQesGv7ZtLi_MpC1HKaxMz9uJ4++v=vNzHpCqd92RB_Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div><font size="4"><font face="monospace"> - An object is
always accessed by reference. This is what I'm saying
changes; value objects are values. </font></font><span style="font-family:monospace;font-size:large">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. </span></div>
</blockquote>
<div><br>
</div>
<div>
<div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
Are we getting any closer, or just digging in?<br>
</body>
</html>