User model: terminology

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "valhalla-spec-experts" <valhalla-spec-experts at 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