FWIW, this was the intuition I was leaning into: > 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.”
Making a distinction between object and instance is likely to be confusing and irritating to users. So I was leaning into preserving these common intuitions: - users declare classes - classes have instances - instances are objects - objects/instances know what class they are And extending them to “and now, the primitives are objects/instances too” (which I think is an evolution people will like, because it moves us towards “everything is an object.”). The new bit, which is the cost of all this, is that for at least id-free objects, there are TWO ways to put them in a variable: put the object itself in a variable, or put a reference to the object in a variable. This is a tricky new concept, but it is consistent with the companion-types model: the value set of C.val are the instances of C; the value set of C.ref are *references to* the instances of C.
