[External] : Re: The good and the bad static pattern ?

[forax at univ-mlv.fr]

> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 22 Janvier 2021 14:26:41
> Objet: Re: [External] : Re: The good and the bad static pattern ?

> On 21/01/2021 16:13, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>>> OK, so it is the "target to argument shifting" that is weird to you? That when
>>> we declare a static pattern, there is a special first argument that is the
>>> target ?
>> The sementics implies an instanceof on something which is not not visible in the
>> syntax.
>> People, me including, will have hard time to debug that, why this pattern is not
>> chosen, oh, it's because of the instanceof.

> I get where you are coming from. But isn't this "more of the same" e.g. the same
> "problem" we have with unbound method references ?
yes and no, 
yes, because if you look just at the expression Baz::print you do not have enough information, you need to know the target type and if print is an instance method or not 
and no because as your example below show, with an unbounded method reference it doesn't compile, with a qualified pattern to a static method, it will compile but because of the instanceof, the code of the case will not be executed, which is an error harder to find. 

Rémi 

> interface Foo {
> void m(Bar b, String s);
> }

> class Baz {
> void print(String) { ... }
> }

> Foo foo = Baz::print // error - why? Ohhh Baz is not a Bar...

> In other words, there are other parts of the language where we play around the
> edges of the static vs. non-static boundary by sprinkling some inference -
> isn't a static pattern another of those cases?

> Cheers
> Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210122/4a4110a1/attachment-0001.htm>