> From: "Brian Goetz" <brian.go...@oracle.com> > To: "Kevin Bourrillion" <kev...@google.com> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@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:kev...@google.com | >> kev...@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:kev...@google.com | >> kev...@google.com ]
