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.
The main problem I think we can't escape is that we'll still need some
word that means only the eight predefined types. (For the sake of
argument let's assume we can pick one and lean hard on it, whether
that's "predefined", "built-in", "elemental", "leaf type", or whatever.)
I've been calling them the built-in primitives; we've test-driven other
terms like "basic" primitives. Assume we'll agree on a term. Also, no
matter how we try, they will be different from the extended primitives
in some ways, such as:
- 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."
There may be others asymmetries too, that derive from compatibility
constraints. As you say, the game is minimization.
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 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?
