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

[Brian Goetz]

>     Remi, is your discomfort about static patterns basically "Well,
>     Scala gets away with having only one kind, that subsumes
>     deconstruction and static, isn't that good enough?" 
>
>
> Not exactly, it's more than if a static pattern that reference a 
> static method, the type of the first parameter is not visible for a user.

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?

>
> Let my try to explain in a simple way.
>
> when we write
>   Object o = ...
>   switch(o) {
>     case Bar$$foo(3, var value) -> ...
>   }

Let's not allow ourselves to be distracted by input arguments yet. (I 
understand this adds challenges but if we're having trouble getting a 
shared understanding the base case, let's not jump to the general case 
yet.)  So I will rewrite your example as:

     Object o = ...
     switch (o) {
         case Bar$$foo(var value) -> ...
     }

There are a series of things going on here that the user must 
understand, in order to understand this code.

1.  Overload resolution.  The pattern Bar$$foo(var value) corresponds to 
a pattern actually declared in some code somewhere. The user has to be 
able to reason as to how this pattern maps to this declared member.  
This is not all that different from methods; when we see `foo(x)` we 
have to figure out whether this is really `this.foo(x)` in the current 
class, a static foo(x), a static-imported method foo(x), etc.  I don't 
think it's any harder for patterns, just a little different.  The user 
should be able to navigate to / find the Javadoc for Bar$$foo.

2.  When we look at the declaration for Bar$$foo, we're going to see 
that it takes one argument and has one binding.  We're going to have to 
understand that the switch target is magically piped into that 
argument.  (For dtor/instance patterns, the same is true, it is just 
magically piped to the receiver, which is an invisible first argument.)

3.  If the target type of the pattern (the type of the target parameter) 
is not total on the static type of the target (Object), the compiler 
introduces a dynamic type test before invoking the pattern body, and if 
this type test fails, the match fails and we move on to the next case.  
This is true for all kinds of patterns, not just static ones; the 
difference is how we determine the type of the target.

Which of these seem problematic to you?  (Note that none of the above 
are specific to static patterns, but all are affected by static-ness vs 
instance-ness, in that we have a different way to declare and find the 
target type from a static pattern.)

>
> Here, I've no idea if foo takes a String, an Integer or whatever as 
> first parameter, so i've no idea on which class the instanceof is done.

It seems that it is #2 that is disturbing?  How is "look at the 
declaration or Javadoc of the pattern" (just like any other API point) 
not a good answer here?

>
> Rémi
> PS: i don't know if you know the following paper that uses polymorphic 
> extractors https://dl.acm.org/doi/abs/10.1145/3357765.3359522 
> <https://urldefense.com/v3/__https://dl.acm.org/doi/abs/10.1145/3357765.3359522__;!!GqivPVa7Brio!LSavgCsfyyi8epi_Nt0kweUe-BucNP7UJ1mv1ImwLZIYR7kRGD-7Tm28O1Kbg6-WDQ$>
>

No I haven't, thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210119/64d21a4c/attachment.htm>