Objects vs. values, the continuation

[Remi Forax]

> From: "Kevin Bourrillion" <kevinb at google.com>
> To: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Saturday, April 23, 2022 12:38:12 AM
> Subject: Objects vs. values, the continuation

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

As we discussed earlier, there are two approaches, one is to say that 
instance of class = object | value 
the other is to say that 
instance of class = object = reference object | immediate object 

I prefer the later to the former, because it does not goes against what people already think, said differently we add more vocabulary instead of trying to refine the existing vocabulary. 

I've done several talks on Valhalla, 

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

I've not a clear idea how primitive will be retrofit to be "immediate class" but at some point, we will want ArrayList<int> to be valid with E still bounded by Object, so the sentence "int is not a subtype of java.lang.Object" may be wrong depending how we retrofit existing primitive types. 

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

B2 are nullable immediate objects. 

> 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?

I like "immediate" to characterize objects without a stable address in memory. 

Rémi