where are all the objects?

[Brian Goetz]

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.

Agreed.

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

Yes, sometimes!  And sometimes you are just swimming against the tide.  And sometimes its hard to know which is which :(

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

Sorry, I think I misunderstood, and answered “what do you call an object”.  So let’s circle back: give me your object definition again so I don’t mis-answer again, and I’ll try to come up with a name for it?

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.

Yes, in the taxonomy I’m pushing, a “value object” is one without identity, and is the kind of object you can store directly in variables without going through a reference.  But I don’t think that there are instances of Complex.val and instances of Complex.ref; I think there are instances of *Complex*, and multiple ways to describe/store/access them.

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.

Right.  Though, the difference we historically have (Integer is an identity class that happens to contain a sole int field) is full of accidental detail (accidental identity, ad-hoc boxing and unboxing conversions with magic methods like valueOf, etc) and what we might want to describe this difference as.

The mental model I’ve had for some time, and  which is where .val and .ref come from, is that there are abstract things called Complex, and you can pass/store a Complex by value, or by reference.  The value/reference distinction has meaning from before the days of Java.  We papered over the difference historically by not letting you touch the objects, but always requiring an intermediary (a reference), and *that* is what is changing now.

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

See previous !


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?

With you on this.  I think asking users to reason about “heap objects” vs “inline objects” is pushing them towards the implementation, not the concepts.  They may have to reason about this to understand the performance model, but that’s already advanced material.



On Fri, Jul 22, 2022 at 8:18 AM Brian Goetz <brian.goetz at oracle.com<mailto: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<mailto:kevinb at google.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220722/dc908aed/attachment-0001.htm>