We have to talk about "primitive".

[Kevin Bourrillion]

On Wed, Dec 15, 2021 at 11:17 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> Background: the textbook definition of "primitive" is centered on their
> nature of being elements-not-molecules, and I see no dispute about it.
> Also, there's no disputing the fact that we're allowed to adopt a different
> meaning if we so choose. So that's not even the fatal flaw.
>
> Yes, that's definitely a point against -- these things are "not primitive"
> in the atomic sense.  OTOH, they are *very much like* today's primitives in
> many other ways.  So this is a choice between being strictly linguistically
> accurate and appealing to existing mental models.  Tough choice.
>

My way of trying to cut through tough choices like that is to ask: Which
traits that we associate with primitives today can we assess as being
*essential* to their meaning, and which are the ones that are *incidental*?


 - Their reference companions have weird names (e.g., Integer);
>  - They permit a seemingly circular declaration (i.e., the declaration of
> "class int" will use "int" in its representation);
>  - They will be translated differently, because the VM has built-in
> carriers for I/J/F/D, whereas extended primitives will use the L and Q
> carriers;
>  - There will probably be some special treatment in reflection for these
> eight types;
>
> Most of these are things about which we can say "OK, fine, these are
> historical warts."
>

I think there's a deeper conceptual need as well. To understand something
that can recursively contain things of its own kind, I think many people
want to have a sense of "but where does that all stop?" What are the leaves
in that tree? The answer is "(builtin-)primitives and references", the buck
stops there. The fact that100% of all of your data is all actually made up
of those things alone (grouped into containers like objects) is
significant, to me. So that's an eternal way that they're special that
isn't a historical wart.

An alternative that seems to work fine, in my mental model at least, is:
>
>    - Primitive types are examples of value types, and have always been.
>    - Java never supported any other kinds of value types before, so we
>    didn't distinguish the terms before.
>    - Everything you associate with primitive types remains true.
>    - But most of those traits really come from their value-type-ness.
>
> FTR, there is one big difference, which has a few consequences.  The big
> difference is reference-ness; value and primitive classes give rise to
> reference types, whereas primitive classes additionally give rise to a
> "primitive" type.  That the "primitive" type gives us reference-ness means
> it gives up nullability and non-tearability.
>

I'm not sure I understood this, but I do want to at least add a bullet to
my list:

   - Now, every value type will come along with a corresponding reference
   type. (We didn't need that before because we could just hand-code 8
   reference types and done.)

As for tearability: from *this* perspective 64-bit values are already
technically tearable, so nothing new here. It's from a different
perspective, that of writing a class, where expectations have to be
weakened.


I think what you're saying here, at root, is to give the "value" name to
> extended primitives, and find another name to give to B2?
>

Yes, that's somewhere near the end of my message. I think B2 should stay
centered on the concept of identitylessness.

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com