Terminology bikeshedding summary

[Dan Smith]

EG meeting touched on a few different renaming ideas to consider. Wanted to put those all down in one place.

Personally, I don't have strong feelings about any of these. I think the status quo is reasonable, and these changes would probably be fine, too (modulo coming up with the right word in some cases).

Some of this faces an inherent conflict between different views/models/users, and we won't be able to please everybody; the choice is about which of those views/models/users we want to emphasize.

#1:

value class vs. [something else] class

I don't recall a concrete proposal, but this reflects some discomfort with the idea that "value" is being used differently than when we talk about "the value of a variable" or, from some other languages, a "value type".

#2:

primitive class vs. bare value class vs. [something else] value class
primitive type vs. bare value type vs. [something else] value type
primitive value vs. bare value vs. [something else] value

Three objections to "primitive":

- Asking developers to loosen their notion of "primitive" to include user-defined, composite types may be too much of a conceptual shift/abuse of terminology

- The original 8 primitives still have a number of properties that make them special, perhaps deserving a convenient, one-word name (on the other hand, *not* giving them a distinct name helpfully communicates that these differences should not be considered significant...)

- It's useful to highlight that these things are still a kind of value class, in some sense reducing the conceptual overhead (there are identity classes and value classes, everything else is secondary)

#3:

primitive value vs. object

We're trying to make a distinction between primitive values being "class instances" and calling them "objects", but for many developers, especially beginners, that sounds like meaningless pedantry. We might be over-rotating on the subtle differences that make these entities distinct, rather than acknowledging that, with their fields and methods, they will be commonly understood to be a kind of object.