[External] : Re: User model: terminology

[Brian Goetz]

>
> What *is* identity? I'll claim it's exactly like an ordinary immutable 
> field-based property, with one special provision: it is *always* 
> auto-assigned to be unique, and thus can never be copied. That feels 
> to me like it tells the whole story. So the difference between these 
> kinds of objects is exactly a "with identity" / "without identity" 
> distinction, and as we know from interface naming ("HasFoo"), it is 
> often impossible to turn that into adjective form.

There's an interesting parallel with nullability here, where nullability 
is also like an immutable field-based property, which is automatically 
checked before accessing other fields.

> The second complication here is the backward default. *Having* 
> identity is actually the special property! I do think we should lean 
> into that. Part of upgrading your code to be "Java 21-modern" (or 
> whatever) really should be marking all your classes that you really 
> *want* to have identity and letting the rest lose it. The terms that 
> feel right are "identity object" and "class that produces identity 
> objects" shortened to "identity class".

In addition to having picked a few wrong defaults in the past, we have 
also committed the sin of not making both states denotable; there are no 
keywords for the opposite of static, abstract, or final, or for 
package-private access.  (Part of the motivation for putting the non-X 
stake in the ground that did with non-sealed is to provide an easy 
extension to non-abstract, non-final, non-static, if we later want.)  
Not being able to denote "identity class" except by the absence of some 
other keywords would be another instance of that.

>     - 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.)
>
>
> I think this term we really need is this one's negation. You never 
> need to (or can) mention it with identity classes; with the rest you 
> can use it to opt into more risk. The English words that come to mind 
> are https://www.thesaurus.com/browse/fragile 
> <https://urldefense.com/v3/__https://www.thesaurus.com/browse/fragile__;!!ACWV5N9M2RV99hQ!NPBDak8nHT2gphJA0fD58S9nj9V1-O5xUyBd2nxtpk2hxoVd-9j08O_pZ8jje-dwBjEwf_GjQjVeQvGq$>.

"Fragile" certainly will make people think twice about using it (and is 
effective estoppel against "but something bad happened").

>
>      - 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 think we need to name the *type* first before the class. Today we have
>
> 1. primitive types (the values are the instances)
> 2. reference types (the values are references to the instances)
>
> But this isn't the *heart* of what it means to be "primitive"; it just 
> happens to be true of primitives so far. And sure, we'll certainly 
> explain all of this *partly* by saying these types are 
> "primitive-LIKE". But what is the quality that they and true primitive 
> types have in common? It's "the values are the instances", so this can 
> either lead to "value type" or go back to "inline/direct/immediate type".

You can make a good argument that this is where we should use the V-word 
(primitives are value types, as are the val projection of B3 classes), 
and come up with a better name for the whole B2/B3 spectrum (such as 
non-identity classes.)  It connects to why we chose value in the first 
place -- to evoke "passed by value".

> Then, back to your question, what is the name for a *class* that 
> *also* gives rise to a value type -- a "valuable class"?
>
>      - A term for what we've been calling the "ref" and "val"
>     projections.
>
>
> Note I think we should only invoke the concept of "projection" once we 
> get into type variables. Otherwise we simply have two types for one 
> class. (And the reason for that is very solid / easy to defend, just 
> by appealing to how we'd've preferred int and Integer had worked.) I 
> would just call them the reference type and the (name debated just 
> above) type, simple as that.

So a "valuable" class has a reference type and a value type.  How does 
that related to nullity?  Obviously the reference type is nullable and 
the value type is not, but do we want to use nullability in the user 
description / type denotation, or should we stick with value and reference?