On Jul 17, 2022, at 12:21 PM, Brian Goetz 
<[email protected]<mailto:[email protected]>> wrote:

Abstractly, my conception of “object” is that it is a bundle of type state, 
identity (optionally), and zero or more fields.  I think this most closely 
corresponds to Kevin’s notion of “compound value”, though it might only have 
zero or one fields — but since there is type state and potentially identity, it 
is still a composite.  Historically we touched objects only through references, 
and we can still do so for all objects, but we now have the ability that a 
variable can store some objects directly.

How we choose to see the formerly-primitive types is mostly a matter of 
choosing which fiction we prefer.  At the VM level, we have I/J/F/D carriers, 
which are definitely some sort of primitive value.  At the language level, we 
can tell ourselves that `int` is an identity-free direct instance of class 
Integer, if we like (though we still have to cut off the turtle-regress when 
declaring Integer.java.).


I think some of us would like to reserve the term “object” for something that 
has a header and a storage block in the heap.

I’m not in that camp.  The header and storage block is how we reassociate type 
state with a (non-flattened) object *reference*.  But a field of type C.val 
stores its typestate “statically”, in the field descriptor.  (Theoretically, a 
field of type C.ref could too, though we don’t currently make that 
optimization.). But these are all just implementation options a JVM has.

In the most idealized version of this world, values are either “bare objects” 
(bag of type state and fields) or references to objects.  In the slightly less 
idealized version, we would call out the legacy primitives as distinguished 
bare values.

Relevant to this: we talked about the "object" term in a January EG meeting; my 
summary at the time (subject "Terminology bikeshedding summary"):

"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."

Reply via email to