> From: "Brian Goetz" <brian.go...@oracle.com> > To: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Sent: Wednesday, May 4, 2022 5:05:24 PM > Subject: User model: terminology
> Let's talk about terminology. (This is getting dangerously close to a > call-for-bikeshed, so let's exercise restraint.) > Currently, we have primitives and classes/references, where primitives have > box/wrapper reference companions. The original goal of Bucket 3 was to model > primitive/box pairs. We have tentatively been calling these "primitives", but > there are good arguments why we should not overload this term. > We have tentatively assigned the phrase "value class" to all identity-free > classes, but it is also possible we can use value to describe what we've been > calling primitives, and use something else (identity-free, non-identity) to > describe the bigger family. > So, in our search for how to stack the user model, we should bear in mind that > names that have been tentatively assigned to one thing might be a better fit > for something else (e.g., the "new primitives"). We are looking for: > - A term for all non-identity classes. (Previously, all classes had identity.) I've used the term "immediate", immediate object vs reference object. > - A term for what we've been calling atomicity: that instances cannot appear > to > be torn, even when published under race. (Previously, all classes had this > property.) As you said, the default should be non-tearable. I believe that we should use a term that indicates that the object is composed of several values, a term like "compound", "composite" or perhaps "aggregate". I think i prefer compound due to its Latin root. The other solution is instead of saying that it's non-terable by default, is to force users to always use a keyword to indicate the "atomiciy" state, (non-)splitable, (non-)secable (secable is more or less the latin equivalent of the greek atomic). > - A term for those non-identity classes which do not _require_ a reference. > These must have a valid zero, and give rise to two types, what we've been > calling the "ref" and "val" projections. I like "zero-default" (as opposite of null-default) but mostly because it's a valid hyphenated keyword. > - A term for what we've been calling the "ref" and "val" projections. Technically, what we called the ref projection is now a nullable projection, we are adding null into the set of possible values. > Let's start with _terms_, not _declaration syntax_. Rémi
