Objects vs. values, the continuation

[Brian Goetz]

Overall I find a lot to like about this presentation.   I’m still a little iffy about whether we can redefine the letters o-b-j-e-c-t in this way, but that is largely a “syntax” reaction to your statements; the substance of the statements sounds about right.

I especially like this bit:

The way I think bucket 2 can and should be explained is: "in the programming model it absolutely is an object. In the performance model, the VM can replace it undetectably with a (compound) value. But that is behind the scenes; it's still behaviorally an object and don't feel bad about calling it an object." To me this is very simple and sensible.

I think what is missing from our presentation — and likely key to succeeding — is how to describe “compound value” in a way that feels like a thing.  Users mostly understand how primitives are different from objects, but “loose bag of primitives with limited integrity constraints” is a new and complex concept that I worry users will have a hard time keeping separate from their conception of object.  Once we start aggregating fields, the temptation is to say “that’s like an object” and then carry with it some incorrect assumptions of integrity (e.g., final field guarantees)


On Apr 22, 2022, at 6:38 PM, Kevin Bourrillion <kevinb at google.com<mailto:kevinb at google.com>> wrote:

I'd like to remind everyone about this (self-important-sounding) document I shared some months ago: Data in Java programs: a basic conceptual model<https://docs.google.com/document/d/1J-a_K87P-R3TscD4uW2Qsbt5BlBR_7uX_BekwJ5BLSE/preview>

I may have undersold it a bit last time. True, it's not the final word on the only possible conceptual model anyone could ever form; however, it is at least a very extensively thought-out and reviewed and self-consistent one. I've also revised it a lot since you saw it (and it's still open for review). If nothing else, at least when I make arguments on this list you don't have to wonder what they are based on; I've laid it all out in black and white. And on that subject...

The crux of that doc for Valhalla purposes is its clear separation between objects and values as wholly disjoint concepts.

An object: has its own independent existence; is self-describing, thus can be polymorphic; is always indirected / accessed via reference; is eligible to have identity.

A value: has no independent existence; is container-described, thus is strictly monomorphic; is always used directly / inline; cannot have identity. (Yes, I'm glossing over that references are also values, here.)

What unifies objects and values (setting aside references) is that they are all instances.

(First, to parrot Brian of a while ago: for a primitive type, the values are the instances of the type; for a reference type, the values are references to the instances of the type, those instances being objects.)

Some instances are of a type that came from a class, so they get to have members. Some instances of are of a type that never used to have a class, but will now (int, etc.) -- yay. And some are of array types, which act like halfway-fake classes with a few halfway-fake members. Members for everybody, more or less!

Though we have at times said "the goal of Valhalla is to make everything an object", I claim the unification we really want is for everything to be a class instance. I think that gives us enough common ground to focus on when we don't otherwise know which thing the thing is (e.g. with a type variable).

One thing I like very much about this is that it fits perfectly with the fact that Integer is a subtype of Object and int is not.

The way I think bucket 2 can and should be explained is: "in the programming model it absolutely is an object. In the performance model, the VM can replace it undetectably with a (compound) value. But that is behind the scenes; it's still behaviorally an object and don't feel bad about calling it an object." To me this is very simple and sensible.

If we instead want to say "the int value 5 is an object now too", then we have some problems:

* I think it ruins those clean explanations just given
* we'd need to coin some new term to mean exactly what I've just proposed that "object" mean, and I have no idea what that would be (do you?)

What are the latest thoughts on this?

--
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com<mailto:kevinb at google.com>