Finding the spirit of L-World

[John Rose]

On Feb 28, 2019, at 10:13 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> the example from John,
>>   Object o = new Object();
>>   o instanceof RefObject
> 
> One way to fix this is:  have `new Object` instantiate not an Object, but a RefObject. (This sort of recognizes that Object is half interface, half class.)

Yes.  This proposal factors out the non-interface parts of Object into
RefObject, which is a great move.

> The weird part is that then “new Object().getClass() != Object.class.  

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.

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

Then, given `var x = new Object()`, the value of `x.getClass()` would
truly be `Object.class`, but the value of `x.getSpecies()` would be
`RefObject.class`.  The Core Reflection API could be tweaked in a similar
way, so that `String.class.getSuperClass()` would return `Object.class`
but `String.class.getSuperSpecies()` would return `RefObject.class`.

Here I'm assuming a particular approach to updating Core Reflection
to handle the new specialized types which will be popping up everywhere.
My point here is that whatever detailed adaptations we make to
Core Reflection for species could be made to apply to Object/RefObject.

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.

Maybe `RefObject` and `ValObject` can be specially-marked classes
today, and promoted to species tomorrow.  With the risk that the
promotion would fail and they'd be specially-marked one-offs
forever.  Maybe that risk is acceptable.  `Object` is already a one-off
special class, so it's not terribly surprising that it would refactor
into three one-offs.  We'd try to rationalize `RefObject` with templates
about the same time we rationalize the primitives as `ValObject`s.

— John