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