(Okay, so we're doing this) I think the rename to "primitive classes" happened during my outage last year. When I came back I made the decision to like it.
Since then, I've found that in my explanatory model I'm fighting against it constantly. I think it may actually be fatally flawed. The points I raise here were surely already known at the time, and I know there were good reasons for overriding them. But I feel the need to come back and push harder on their importance. 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. 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.) Definitely, our trying to minimize their specialness is virtuous. They should be like helium: yes, they are molecules when you want a molecule! But on any deeper look they will clearly be "actually" elements, and the distinction will matter often enough. So we have to attempt to shift users' understanding of "primitive" while at the same time injecting a new term to mean exactly what primitive used to mean. That's the old Indiana Jones switch and I don't have to tell you how that turned out for him. It would be difficult to pull off in a world where we were just pushing some new server and the whole world gets the new model at once. But in this universe where every version of Java ever made all have to coexist, it's looking to me like a guaranteed source of never-ending confusion. I also think it robs us of our ability to smoothly portray the real changes of Valhalla. We want to be able to say "elements are still elements! now we have molecules too". Pedagogically that is always preferable to "elements aren't really what you thought they were". Okay, the real comparison is a little more nuanced than that, but I'll get to that now. 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. (I plan to make the above shifts to my model document already.) - Now we have user-defined value types too. - The way we user-define a type is with a class, so a value type is defined by a "value class" (sorry B2). - The primitive types will now each get a value class. - These 8 classes will look as much like user-defined types as Object does. - They, like Object, will have a "cheat" in their source code that no one else gets to use. (Object's is that there is no implied `extends Object` or `super();`; these need no fields because the data they store is magically handled by the VM. These feel like similar cheats.) Then mopping up the rest: - Existing classes probably need a term like "reference classes" (in the model I'm going to circulate that doubles down on values-are-not-objects, then this wants to be "object classes", even though that feels weird at first). - I think the term for bucket 2 classes really ought to center on identitylessness, e.g. "noid", "noident", "idfree", or something. Anything else is getting away from the essential meaning of the bucket; plus, we want people to call bucket 1 classes "identity classes", don't we? Footnote: for a more concrete manifestation of this problem: I am sure we cannot possibly get away with Class.isPrimitive() being true for these classes. Right? Thoughts? -- Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
