> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Maurizio Cimadamore" <maurizio.cimadam...@oracle.com> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Lundi 15 Avril 2019 17:23:36 > Objet: Re: RefObject and ValObject
>> Your idea of treating Object as abstract is, I believe, a sound one (which >> doesn't need any extra rule) - but we might have to figure out some story for >> anonymous inner classes of the kind `new Object() { ... }`. > After thinking about it for all of five minutes, I think this may have broken > the logjam (or, at least the current logjam.). We’ve been asking ourselves > whether RO/VO are classes or interfaces, when we didn’t really consider > abstract classes. Which we didn’t consider because we had assumed that the > concrete-ness of Object was nailed down. Let’s assume it’s not. > Then we have: > abstract class Object { } > abstract class RefObject <: Object { } > abstract class ValObject <: Object { } > Existing classes that extend Object are silently reparented to RefObject, both > at compile time and runtime. This may have some small .getSuperclass() > anomalies but this seems pretty minor. Same with anon classes of Object. > Inline > classes implicitly extend ValObject. > We add a method `Object::newInstance` (name to be bikeshod later.). We start > warning in the compiler on `new Object`, to motivate migration to > `Object::newInstance`. Runtime rewrites these too. > There are some minor behavioral compatibility issues here, but they seem > pretty > minor, and in the end, we end up with a hierarchy that describes the way we > want users to see the type system. It's not a minor change, and all code that uses a type parameter that have Object as bound will become ambiguous. Rémi