One way to fix that and other reflective artifacts, is to piggy-back
on specialized generics and their refined type system. In the spirit
of brainstorming, let's pull on that string a bit.
We could declare that `RefObject` is a *species* of `Object`, not
a subclass. Then, `Object` is revealed to be a template with just
two species.
As I was writing, I knew that this was where you were going to go.
What that means is that we layer another requirement onto species; that
they be denotable with simple names. I am not sure we want to go there,
just for the sake of this one example?
(The species parameter of `Object<hasIdentity>` could be `<true>`
for `RefObject`, etc. …Shots fired! Look out, he's got a non-type in
his parameter list! Or the species parameter could be a placeholder
type of some sort.)
This is a sensible possible place to get to, but it means we give up the
pedagogical benefit of RefObject/ValObject being "just" Java classes.
If we can't write these in Java, that's a big loss; having to have
generics with non-type parameters on Day 1 does a lot of damage to the
delivery plan.
Since templates aren't ready yet, this can't be a fully-baked proposal,
but it could work in the long term. Maybe that suggests a short term
approximation? Should we be talking about `Object<Ref>` and
`Object<Val>` as injected species, rather than `RefObject` and
`ValObject`? They would have conditional members, whatever that
means. That also feels like an unnecessary complexity now, but
it might be more appropriate in a world with templates.
Yeah, also, think about the first day of class. Everything is an
Object, they say. OK, fine, whatever an Object is. Now, some objects
are Object<Ref>, and some are Object<Val>, which are sub-species ....
WTF? This is putting a grad-school concept on the 3rd grade curriculum.
An alternate approach (which in general I don't love, but could be made
to work) is to make {Ref,Val}Object interfaces. I think its a weaker
semantic story, but maybe its viable. In that case, we could have a
(private) sub-species of Object that implements RefObject, and that's
what you'd get when you say "new Object()". Then .getClass() is
stable. But to do it for this reason seems like
flea-wagging-tail-wagging-dog.
The hybrid approach, which happens to work in this case, is have
RefObject be an interface and ValObject be a class. Again, I don't like
it as much as subclasses, but it's not outright unacceptable. It's a
little better on the implementation-perturbations and a bit worse on the
providing-a-sensible-user-model side.
