[External] : Re: User model: terminology

[Brian Goetz]

While on the subject of defaults: we've been treating B2 as the default 
kind of non-identity class, on the theory that it is the smallest hop 
away from identity classes, and also that it covers a broader range (all 
the existing value-based classes.)  Is that still the default we want?

Flipping that default might make framing the B2/B3 distinction easier: 
rather than "tolerant of zero", what we'd opt into is "ref only".

<bikeshed>

Pulling farther, there's a bucket-inversion we might be able to pull 
here, just by moving some terminology around:

     class B1 { }                 // ref only
     value class B3 { }           // ref and val projections
     value-based class B2 { }     // ref only

And then we can apply non-atomic / fragile (or whatever we call it) to 
either B2 or B3.

This has a few positive properties:

  - Connection to the existing term "value-based", which means "follows 
the value constraints, but is a ref type", and has the connotation of 
"approximation of a value class"
  - .val makes sense in the context of a "value class"
  - We get the orthogonality we are seeking, but avoid piling up lots of 
modifiers (non-atomic zero-happy value class) as well as not having to 
invent crazy words like "zero-happy"
  - Practical difference between .val and .ref is just about nullity now
  - We get the "must opt into non-atomicity" that Brian has been ranting 
about

This basically leaves the bucket model intact, with some flipped 
terminology, but importantly, factors atomicity out of being an implicit 
bucket property, and instead an explicit global choice.  This is by far 
the most important aspect of the restack I am pushing.

It is an orthogonal choice as to whether .val or .ref gets the "good" 
name for value classes.

On the negative side, there is an extra syntactic burden to get to B2 
compared to B3 (value-based instead of value) which might cause some 
developers to reach for it when they might prefer VBC. But if the 
default for B3 is .ref, it might not matter as much (they're both ref 
types and you still get integrity), so the only risk is accidental 
exposure of the zero value.

</bikeshed>

On 5/4/2022 2:27 PM, Kevin Bourrillion wrote:
> My favorite kind of thread...
>
> At the risk of inducing groans, a reminder that much of my own 
> terminology backstory is found in Data in Java Programs 
> <https://urldefense.com/v3/__https://docs.google.com/document/d/1J-a_K87P-R3TscD4uW2Qsbt5BlBR_7uX_BekwJ5BLSE/preview__;!!ACWV5N9M2RV99hQ!NPBDak8nHT2gphJA0fD58S9nj9V1-O5xUyBd2nxtpk2hxoVd-9j08O_pZ8jje-dwBjEwf_GjQis3lrdF$>, 
> and that when there are places we disagree below, the disagreement is 
> probably highlighted by something in *that* document first.
>
> Since for all we know it might be out of step with how typical Java 
> devs really think, I'll just mention that it's at least been 
> well-received by reddit 
> <https://urldefense.com/v3/__https://www.reddit.com/r/java/search/?q=*22data*20in*20java*20programs*22__;JSUlJSU!!ACWV5N9M2RV99hQ!NPBDak8nHT2gphJA0fD58S9nj9V1-O5xUyBd2nxtpk2hxoVd-9j08O_pZ8jje-dwBjEwf_GjQo7MMfgr$> 
> twice (if reddit can find something to complain about, they usually do!).
>
>
> On Wed, May 4, 2022 at 8:05 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
>     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.)
>
>
> The term applies to the objects first and foremost. The object either 
> has identity or does not.
>
> 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.
>
> 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".
>
> For the most part I think we'll end up talking about "identity 
> classes" and "classes in general", and more rarely needing to refer to 
> "classes without identity" or "non-identity classes". So I think it's 
> okay to let them use "A \ B"-style terminology as I've done here. (I 
> furthermore still think it's okay to have an IdentityObject interface 
> but no ValueObject interface, as the latter doesn't really embody 
> additional client-facing capabilities.)
>
> This is one of at least four examples of backward defaults in the 
> language. We are either stuck with painful/awkward terminology choices 
> in all of them, or we could pursue the idea of letting source files 
> declare their language level, upon which the problem vanishes.
>
>     - 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$>.
>
>      - 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".
>
> At this moment I like both "value type" and "inline type" well enough. 
> Value *is* overloaded, to be sure, because of "value semantics" (aka 
> why AutoValue is called AutoValue). But the connection is strong 
> enough imho. I can delve deep into this topic if desired.
>
> 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.
>
>     Let's start with _terms_, not _declaration syntax_.
>
>
> Yes, and even the term we like 2nd best for a thing can still be 
> useful in the documentation of that thing.
>
> -- 
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20220504/6ce3a35a/attachment-0001.htm>