RefObject and ValObject

[Remi Forax]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20190415/544916e7/attachment.html>