To the extent we can avoid redefining these things, I think it is
easier to just leave these terms in place.
Uh oh, this makes me worry that I'm already supposed to know what the
distinction is. :-)
In my everyday experience, people sometimes use "object" ambiguously
to refer to the instance or the class, but "instance" to emphasize
the, err, instance.
Is that it?
Instance is defined relative to a class; a given object might be an
instance of the class String, or the class
SimpleBeanProviderFactoryInjector. But they are both objects. We don't
really need two terms, but we've got em.
* Identity objects get the benefits of identity, at the cost
that you may only store /references/ to them. They will
~always go onto the heap (modulo invisible vm tricks).
Yes. Again, pedagogically, I am not sure whether the heap
association is helpful or hurtful; on the one hand, C programmers
will understand the notion of "pointer to heap node", but on the
other, this is focusing on implementation details, not concepts.
/But is/ it an implementation detail? To me, this entire feature is
about memory layout on its face.
At the language level, there are objects and references to objects,
which are of different "kinds". Hitherto, the only way we interacted
with objects is via references, but now there are new kinds of objects
that can be interacted with either directly or indirectly. This are
type-system concepts. We could have this system today, if we just
changed the terminology around primitives. But what we don't like about
this system is the cost of boxing.
At the VM level, it's all references! But, the VM is smart, so it knows
how to do magic VM stuff when it encounters references to identity-less
objects. This should _routinely_ turn into flattening, though the VM
reserves the right to refuse to flatten, if, say, your inline class has
64,000 fields.
I think the key word is _routinely_. With the information we give the
VM, we should expect to get certain memory layout behavior most of the
time.
So, is that implementation detail or not?
o (Users choose by e.g. writing either `Foo.val` or
`Foo.ref`, though one would be the default)
Yes. It is worth noting here that we would like for the actual
incidence of `.ref` and `.val` in real code to be almost
negligible. Maurizio likens them to "raw types", in the sense
that we need them to complete the type system, and there are cases
where they are unavoidable, but the other 99.9% of the time, you
just say "Point".
This aspiration strikes me as highly... aspirational. :-) Isn't the
user pushed into this the second they call `Map.get()`?
Well:
var x = map.get(k);
if (x != null) { ... }
But, if they want a manifest type, they have two choices:
V.ref x = map.get() // oops, caught in Kevin's trap
V x = map.get() // uses inline narrowing, which would NPE if
the item is not in the map
All that said, Map::get is not really a natural idiom in a work with
inlines, and so we would likely provide other ways to interact with a
Map that are less null-centric; an optional-bearing version, a pattern
match, a lambda-accepting version, etc. So I think this is in the
category of migration help; we're working with a legacy method whose
protocol is inherently null-centric.
Where we expect .ref and .val to show up are:
- Migrated classes -- such as Optional
- APIs that assume nullability -- such as Map::get
- When you need to express "V or null"
- When you explicitly do not want flattening for reasons of memory
footprint (say, a sparse array of fat inline objects)
(At one point we thought erasure was on this list, but we're having
second thoughts on that.)
* A concrete /class/ is either an "identity class" or an
"inline class". But a compile-time /type/ is distinguished
not by "inline vs identity" but by "inline vs /reference/".
Yeah, this is the other hard one. In fact, it took us years to
realize that the key distinction is not reference vs
primitive/inline, but _identity_ vs inline.
Did I have it backwards?
No, you had it right.
