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 <kev...@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. | kev...@google.com
