Finding the spirit of L-World

Brian Goetz brian.goetz at
Thu Feb 28 21:04:27 UTC 2019

> 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 

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.

More information about the valhalla-spec-observers mailing list