where are all the objects?

[Kevin Bourrillion]

I do understand where you're coming from, but I feel strongly that we
cannot make a judgment about which way is more "meaningless pedantry" than
the other without a *complete* picture of all the terms we will use for
necessary concepts, and how our explanations come out using those terms.

I also feel strongly that we need to accept that *no matter which* way we
go, there will be some terminology clarifications we need to make that will
rub users the wrong way, where they used to think "X always means Y", and
we start telling them "not anymore". All my work has been toward trying to
understand *which* of these breaks are more or less damaging than others
and why. It doesn't work to just cite the disadvantages of one particular
shift as self-sufficient argument that we shouldn't do it. It's about pain
A vs. pains B/C.

Note that *some* decisions which produce strong initial antipathy in the
minds of users will actually become good teachable moments! "Here's why the
reaction you had was tied to old assumptions that we are intentionally
leaving behind for these good reasons." Even a user who doesn't *agree* with
the decision can still hang their *learning* onto this. In fact I think
some of the *best* teachable moments will be like that. But not all such
breaks we could make will be so teachable; some will yield persistent
confusion. (This is part of what I meant by "more/less damaging" just
above.)

"My way" (i.e. that I've been advocating thus for) might not be the right
way in the end, but I've not gotten as clear of an understanding of the
alternative. Brian, I think you declined *twice* on this thread to answer
my question of what you would call the thing that I've precisely called
"object" (once being off-list (my bad)). John finally volunteered (also
off-list (my bad)) "heap object"; okay then, that at least lets us put
together a more complete picture that we can evaluate the pros and cons of.

So then, would we call an instance of `Complex.val` a "non-heap object" or
an "inlined object" or what? We need to flesh out a whole lexicon. The
phrase "value object" becomes useless for this particular distinction as it
will apply to both.

Users don't always have a stable and precisely developed vocabulary (I sure
didn't until I had to work all this stuff through for this group), but what
we do have, deeply, is our years of experience understanding *the
difference between int and Integer* and how to make that choice in our
code. (There's a principle in here somewhere that oughtta be stated in some
better way than this: users will know the distinctions between concepts if
those are the distinctions that have actively driven the *decisions* those
users have had to make, and not as much otherwise.)

I think the best thing we can do for users is make it clear and natural for
them *what that carries over to*, exactly, in the new world. I've been
advocating for saying:

That `int/Integer` decision you've been making has always been between (1)
value and (2) (reference-to) object, and that decision is *still* exactly
between (1) value and (2) (reference-to) object now, and btw the
definitions of 'reference' and 'object' remain precisely wedded to each
other as always.

The "heap object" alternative strikes me (and I am *trying* to be fair,
here) as:

Now, that's an object either way, and you're going to apply that old
thought process toward which *kind* of object you mean, either a (1)
"inline object" or a (2) "(reference-to) heap object". It's now just heap
objects and references that are paired together.


Starting to prefer the first way (as I did) did not feel like going rogue:
after all, did we not gravitate toward ".ref" and ".val" as our placeholder
syntaxes, not ".inline" and ".heap" or anything else?


On Fri, Jul 22, 2022 at 8:18 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> FWIW, this was the intuition I was leaning into:
>
> > We're trying to make a distinction between primitive values being "class
> instances" and calling them "objects", but for many developers, especially
> beginners, that sounds like meaningless pedantry. We might be over-rotating
> on the subtle differences that make these entities distinct, rather than
> acknowledging that, with their fields and methods, they will be commonly
> understood to be a kind of object.”
>
>
> Making a distinction between object and instance is likely to be confusing
> and irritating to users.  So I was leaning into preserving these common
> intuitions:
>
>  - users declare classes
>  - classes have instances
>  - instances are objects
>  - objects/instances know what class they are
>
> And extending them to “and now, the primitives are objects/instances too”
> (which I think is an evolution people will like, because it moves us
> towards “everything is an object.”).
>
> The new bit, which is the cost of all this, is that for at least id-free
> objects, there are TWO ways to put them in a variable: put the object
> itself in a variable, or put a reference to the object in a variable.  This
> is a tricky new concept, but it is consistent with the companion-types
> model: the value set of C.val are the instances of C; the value set of
> C.ref are *references to* the instances of C.
>
>
>

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220722/f9f73318/attachment-0001.htm>