identityless objects and the type hierarchy

[Kevin Bourrillion]

Okay, let's stick a pin in proper-value-types (i.e. try to leave them out
of this discussion) for a moment...

One question is whether the existing design for the bifurcated type
hierarchy will carry right over to this split instead. (My understanding of
that design is: every (non-Object) concrete class will implement exactly
one of two disjoint interfaces, explicitly or not.)

My first thoughts were that the situation is different here: exposed
identity seems to be strictly (maybe?) contractually stronger than no
exposed identity. So here, a class being "noncommittal" *ought to* look the
same as it being identityless. In theory, it should be harmless for an
identity class to extend an identityless class (while the opposite
direction is a problem).

So, first, is that even right?

Next, even if so, the Backward Default Problem strikes again. To make a
class identityless you would seem to need all your *supertypes* to be,
first! That's hard to pull off. And `Object` itself would seem to want to
be marked identityless, which is obviously weird/problematic.

So I think we are forced back to a tripartite model (somewhat like we are
having to do with nullness, but probably closer to what we'll have to do
after nullness for `@OkayToIgnoreReturnValue`).

"intentionally identityful" is-stronger-than "intentionally identityless"
is-stronger-than "unknown so will be *presumed* identityful unless
otherwise specified"

It's possible that would put us straight back to where this email started.

But this all smells rotten, like it demands we find a simpler way to think
about it (which you may already know, and I'm just missing it so far).


--
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com