[External] : Re: Can not call a private method, no idea why ?

forax at univ-mlv.fr forax at univ-mlv.fr
Thu Jan 21 14:30:41 UTC 2021


----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Anna Kozlova" <anna.kozlova at jetbrains.com>, "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoyé: Jeudi 21 Janvier 2021 14:11:57
> Objet: Re: [External] : Re: Can not call a private method, no idea why ?

> Some further history - this was tweaked several years ago in 7:
> 
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6246814
> 
> There's also an open RFE on the spec:
> 
> https://bugs.openjdk.java.net/browse/JDK-6644562
> 
> Which basically refers to what we have discussed - e.g. the type system
> rules being too conservative and applying intersection type semantics
> even if there's only one bound.

yes, thanks.

> 
> Maurizio


Rémi

> 
> 
> On 21/01/2021 13:03, Maurizio Cimadamore wrote:
>> I sympathize with your argument: at the end of the day, when you have
>> X <: Foo, you can always widen (e.g. assign) X to Foo (w/o warnings)
>> and take it from there, and all restrictions are gone - so maybe this
>> is excessive hand-holding on the language-side - but I was trying to
>> explain the rationale behind the rules - it is pretty common when
>> dealing with parametric polymorphism to think of membership of a
>> type-variable X in a "for all" semantics - e.g. the intersection of
>> members that are available in all instantiations of X; so, for the
>> language (and the compiler) X <: Foo and Foo are two very different
> > types, with very different membership rules.


More information about the compiler-dev mailing list