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

[Brian Goetz]

OK, I can see how someone could get started out here pointed in the 
wrong direction.  But this is not really that different from static 
methods.  I can have a static method MumbleWidget::reverseString, that 
operates only on strings.  At first, someone might be confused -- "why 
is this method in MumbleWidget but it operates on strings" -- but then 
we go look at the Javadoc, read what arguments it takes and what it 
returns and what it does -- and we're back on track.   I don't really 
see how this is different.

The target of a pattern is right there in the parameter list:

     static<T> pattern(T contents) nonEmptyOptional(Optional<T> target) 
{ ... }

And its likely that the Javadoc would say: "This pattern succeeds if the 
target Optional holds a value.  If so, the binding `t` is bound to the 
contents of the Optional."

Once a user finds the documentation, are you saying you still think it 
this is not something users can understand?  This strikes me more as 
just "in the first reading of my doc, you got pointed in the wrong 
direction."  But that's a matter of pedagogy, not model.

In Scala, the target is also right there in the argument list -- and 
basically all patterns in Scala are static.  Is this a problem for them?

More importantly, as Tagir points out, one of the main benefits of 
static members is that they can be added "outboard", by other classes.  
This is a tremendously useful feature for static methods, and I expect 
it will be the same for static patterns.

> Apart disabling the declaration of a static pattern which doesn't take 
> the class that declares the pattern as first parameter,
> the other solution i see is to not do an instanceof if the first 
> parameter of a static pattern is different from the class that 
> declares it.

This seems like using a nuclear bomb to kill a fly.

It is possible there are syntactic ways to restack the declaration that 
makes the target more obvious (e.g., choose a semi-reserved name for the 
target, like `target`, and require that the first parameter be so 
named), but we can paint that shed when we get to it.


>
>     OK, I think I finally get where you're hung up on static
>     patterns.  There are TWO types involved:
>
>         class MumbleWidget {
>             static<T>  ... pattern(T t) ...
>     nonEmptyOptional(Optional<T> target) ...
>         }
>
>     The types are MumbleWidget and Optional.  To find the pattern, the
>     user says:
>
>          case MumbleWidget.nonEmptyOptional(var x):
>
>     and your concern is that users will see "MumbleWidget.something"
>     and say "Oh, this must be matching a MumbleWidget", and be
>     confused that really it is matching an Optional? 
>
>
> yes !
>


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