Finding the spirit of L-World

[Brian Goetz]

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