Please, no.


> On Apr 15, 2019, at 11:03 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
> 
> 
> 
> 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 16:38:58
> Objet: Re: RefObject and ValObject
> Let's model the value vs. reference constraint explicitly - e.g. with 'val' 
> and 'ref' type kinds (and let's not open the can worm as to what the syntax 
> should be, whether it should be a type anno, etc.)
> 
> So:
> 
> val Object ---> accepts all values
> ref Object ---> accepts all references
> any Object ---> accepts all references
> 
> 
> We explored this sort of thing in Q world.  One place where this really was 
> painful was what it did to generic tvar constraints; we had an entire new 
> algebra of constraints: 
> 
>     <ref T extends Bound> void m(T t) { … }
> 
> Brian,
> val, ref and any only applies to Object.
> 
> if you prefer in term of notation, let's rename ref Object to Object?, val 
> Object to Object! and any Object to Object*,
> 
> you can apply ? on any value type, Object included,
> you can apply ! and * only on Object.
> 
> Object? is erased to Ljava/lang/Object; by the generic signature is 
> Ljava/lang/Object/* (so it's Object for the VM and Object! for the compiler),
> Object! is erased to Qjav/lang/Object;
> Object* is erased to Ljava/lang/Object;
> 
> As a bound of a type variable, Object is equivalent to Object? by backward 
> compatibility.
> and
>   <T extends Object!> void m(T t) { … }
> means that T is not nullable, so it's a value type.
> 
> And at runtime, instead of
>    (o instanceof Object!)
> one will write
>   o.getClass().isValue()
> 
> Rémi
> 
> 
> which was ad hoc and composed terribly.  This hell is _exactly_ the thing 
> that pushed us to Ref/ValObject as _types_ in the first place.  (More of the 
> same: what is “ref Object”.class, and how does it differ from “any 
> Object”.class?).  
> 
> 2) reinterpret `Object` as `any Object`
> 
> That is, the semantics of `Object` is being redefined here - code which 
> assumed to work with references might need to opt-in to additional 
> constraints (e.g. add `ref`) in order to make sure it still work as intended.
> 
> Right.  Q-world tried it the other way, and we were in utter migration hell.  
> There are migration cases in this direction too, but we are convinced they 
> are orders of magnitude fewer.  
> I don't see another way out of this conundrum - other than adding a special 
> rule (z2) which says that `new Object()` is treated specially and always has 
> kind `ref`. But doing so will run afoul in almost every possible way - as 
> soon as you manipulate the result of the `new` in any way (cast, assignment 
> to variable of type `Object`, ...) you go back to `any` and you are back to a 
> place that is incompatible with `ref Object`.
> 
> Yes, this is the cost.  I have to think that given a choice between some 
> weirdness around ’new Object’, and dramatic, awful new kinds of types that 
> complicate type uses, type descriptors, reflection, etc, etc, etc, that 
> making the former work is going to be less painful, both for us and for users.
> 
> 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() { ... }`.
> 
> 
> Right.  And, again, this can be treated as a migration issue, and we can 
> start warning users to migrate their source now. 

Reply via email to