Finding the spirit of L-World

[Remi Forax]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 28 Février 2019 18:17:43
> Objet: Re: Finding the spirit of L-World

>> class Object { ... }
>> class RefObject extends Object { ... }
>> class ValObject extends Object { ... }

> Let’s talk about this one some more. There are some obvious practical benefits
> of bringing these key concepts into the type system. The first is that talking
> about ref vs value can be done with tools we already have:

> if (x instanceof RefObject) { synchronized(x) { … } }

> void m(ValObject vo) { … }

> class Foo<T extends ValObject> { … }

> rather than inventing new ways to talk about “ref only” or “val only”.

One can note that all these examples only need ValObject as the instanceof test can be rewritten has !(x instanceof ValObject) and introducing only ValObject is not an issue. 
Obviously, it's not enough apart if we introduce a kind of negation, like 
class IdentityHashMap<T extends !ValObject> { 

} 

> Another is that ref- or val-specific behavior has an obvious place to live, and
> can be implemented with tools we already have (e.g., final methods.)

> A third is that all objects are no longer created equally; having the “top
> types” reflect this will help users learn and understand this.

> A minor benefit is we no longer need an ACC_VALUE flag; we can just trigger off
> of “extends ValObject”.

> So, what are the costs and risks?

> - JVMs have to rewrite hierarchies so when a class is loaded that extends
> Object, it is rewritten to extend RefObject.
> - Existing code that relies on .getSuperclass() == Object.class might break.
> - Inheritance hierarchies get one deeper, making searches of superclass chains
> one longer.

> Any others?

the example from John, 
Object o = new Object(); 
o instanceof RefObject 

Rémi