Objects vs. values, the continuation

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Kevin Bourrillion" <kevinb at google.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Sunday, April 24, 2022 5:57:57 PM
> Subject: Re: Objects vs. values, the continuation

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

Having loose integrity is a property of primitive class but it's also a property of double and long. 
This is not how we describe long and double, at least not until we introduce the notion of concurrency. 

I think that having a default value / not being null is a property that is easier to understand and easier to grasp than the concept of integrity. 
Or maybe i'm not understanding what integrity really means. 

Rémi 

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

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

>> 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. | [ mailto:kevinb at google.com |
>> kevinb at google.com ]