Objects vs. values, the continuation

[Dan Heidinga]

Hi Kevin,

A question about the "Values" subsection of the "Model" section.  You
draw a distinction between the Platonic value and values as ephemeral
pieces of information.

> A value is less than all that! It's just an ephemeral piece of information being communicated directly from some program element to another.

and footnote 4

 >  "Value" has another, Platonic meaning: there is one and only one
value we call 42, transcending time and space and existence. In this
document I'm discussing a more specific meaning: how to think
concretely about a value inside a running Java program.

And I'm unclear on why the ephemeral information presentation is
prefered to the Platonic meaning?

Conceptually, all values with the same bits and type are
indistinguishable from one another. The locations are mutable, but the
values are effectively Platonic ideals.  Describing them as "summoned
from the Platonic plain" avoids having to try to make a distinction
against the common understanding of "ephemeral" as short-lived.  Does
leaning into the Platonic view ease the number of differences users
have to absorb?

I'm slightly concerned about the presentation of "small" as being
incidental.  While size isn't a critical factor from the programming
model perspective, it is incredibly important for aligning with the
natural physics of the hardware.

> The fact that these are "small" (at most 64 bits) is incidental, not essential; introducing a new quadruple type would not destabilize our concept of a primitive value.

If we can tip the user's mental model so that they believe "small is
good" for B3 values, then we aid them in hitting the sweet space of
the design and help them avoid tearing issues.  It doesn't change the
model but the more we can encourage the belief that B3 values should
be <= 64it the happier users will be with the results.

--Dan

On Fri, Apr 22, 2022 at 6:38 PM Kevin Bourrillion <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
>
> 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