RefObject and ValObject

forax at forax at
Mon Apr 15 21:01:26 UTC 2019

> De: "Maurizio Cimadamore" <maurizio.cimadamore at>
> À: "Brian Goetz" <brian.goetz at>, "Remi Forax" <forax at>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at>
> Envoyé: Lundi 15 Avril 2019 22:53:49
> Objet: Re: RefObject and ValObject

> I think we should be ok inference-wise, except of course for edge cases (like
> vars) which exposes the guts of the inference engine.

> In normal cases like:

> List<Object> list = List.of(new Foo(), new Bar())

> the equality constraint on the LHS should force a solution which overrides the
> new 'RefObject' bound that comes in from the RHS.

> (that is, you have T = Object, then T :> Foo and T :> Bar, so T = Object 'wins',
> even if less precise)

> Maurizio
yes, i think you're right, 


> On 15/04/2019 21:39, Brian Goetz wrote:
>>> 1) any codes that has inference
>>> var list = List.of(new Foo(), new Bar());
>>> will be inferred as List<RefObject> instead of List<Object>, so calling a method
>>> that takes a List<Object> will not compile anymore.

>> Not to dismiss the “what about inference” issue, but any code that combines
>> `var` with `List,of()` should not be surprised at the result of inference ….

>> But, “what about inference” noted.

>>> 2) any code that consider Object as special class may stop working, dynamic
>>> proxies that have a special case for Object, any code that reflect recursively
>>> on the hierarchy to find all the methods, any code that remove getClass() from
>>> the getter list, etc.

>> Absorbing value types is going to require some changes on the part of most
>> frameworks to get best results. This one seems in that category?

>> Again, not to dismiss, keep them coming, but so far this isn’t scaring me away
>> from having the object model that makes most sense.

More information about the valhalla-spec-observers mailing list