On Feb 28, 2019, at 10:13 AM, Brian Goetz <brian.go...@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
