Patterns: declaration

[Brian Goetz]

>
> Hi, Brian,
>
> This exploration of the different ways of declaring patterns is very 
> useful, as
> if the observation that for every sort of constructor or method, there 
> can be a
> corresponding sort of pattern.
>
> I believe, however, that it then falls prey to a fallacy: I believe 
> that it is
> not correct to conclude, just because every sort of constructor or 
> method has a
> corresponding form of pattern, that for every sort of constructor or 
> method the
> corresponding form of pattern should be used.

This is a great point; this is where language design meets library 
design, and while it may be sensible for the language to have all the 
options, perhaps the libraries need not follow the path of least 
resistance.  As a concrete example, let's take Optional.  We have static 
factories Optional.of(x) and Optional.empty(), which are the _only_ ways 
to construct Optionals from outside the capsule.  And clearly, we want 
to capture the conceptual and syntactic symmetry of:

     Optional<String> o = Optional.of(foo);
     ...
     if (o instanceof Optional.of(var foo)) { ... }

But, it eluded me that the second locution need not appeal to a static 
pattern, just because the factory is a static method.  If we define:

     final class Optional<T> {
         static<T> Optional<T> of(T t) { ... }
         pattern(T t) of() { ... }
     }

then the same use-site syntax refers to the instance pattern here. And 
if the target is a broader type than Optional, then either would require 
the same synthetic target-applicability test (is the target an Optional.)

This is your main point, right?

> There is an inherent asymmetry between a static factory method and a 
> pattern:
> the static method has no target, whereas a pattern (whether static or 
> instance)
> _always_ has a target.

Yes, this is an unfortunate asymmetry, because it forces the language to 
give special meaning to a parameter.  (The proposed alternate syntax 
that Tagir and I discussed hide this somewhat, but its still there.)

> I have long felt that static methods in Java are a kind of 
> second-class kludge.

John frequently says: "static has messed up every job we've given it; 
don't give it more jobs to mess up."

> For the first example, this produces code that looks pretty good, 
> because it is
> obviously necessary to indicate a type in addition to the method names:
>
> ```
> switch (myObject) {
>     case Optional.of(var t): ...
>     case Optional.empty(): ...
>     case OptEither.left(var t): ...
>     case OptEither.right(var u): ...
>     case OptEither.empty(): ...
> }
> ```

Allow me to inject a confounding factor: static imports.  We have static 
imports for methods, so you can static import Optional.of, and then say 
`Optional x = new of(y)` if you so desire.  So surely, patterns would 
want the same consideration?

But, this is a confounding factor, I think; it's a matter of specifying 
"pattern selection" carefully, and I believe that saying 
`Qualifier.name(stuff)` vs `name(stuff)` is mostly independent from 
static-ness.  The former could describe either an instance or static 
pattern (modulo same problems we already have with methods, if there are 
instance and static methods with the same name and descriptor), and the 
latter could either determine the qualifier from the static type of the 
switch operator, _or_ from the `import static` context. So either form 
of use could be either form of declaration.

> We can get this concision for the second example by declaring instance 
> patterns
> rather than static patterns to complement the static factory methods.
> Unfortunately, this makes the first example no longer work.

I think the first example can continue to work even if they are instance 
patterns?  We do a member selection for `Optional.of(...)`, discover 
there is an applicable pattern there, that it is an instance pattern on 
Optional<T>, do our target-applicability calculation, and we're off to 
the races?

> Idea (c) is to regard the meaning of a pattern of the form `T.P(...)` as
> depending on whether the pattern P declared in class T is a static 
> pattern or an
> instance pattern.  This allows us to use the originally proposed form 
> with dots:
>
> ```
> switch (myObject) {
>     case Optional.of(var t): ...
>     case Optional.empty(): ...
>     case OptEither.left(var t): ...
>     case OptEither.right(var u): ...
>     case OptEither.empty(): ...
> }
> ```

I think (c) is where we're aiming at now (though to be fair, it was only 
discussed in passing, I think in response to AlanM's recent mail.)

> at the expense of overloading the notation `T.P`, which some 
> programmers might
> find disturbing.

We've already got an analogous overloading, which has actually turned 
out to be super-popular: method references.  Foo::bar is either (a) a 
method reference to the static method bar in Foo, or (b) a method 
reference to the _unbound_ instance method bar in Foo, in which case the 
receiver is added as an extra first parameter (eta abstraction).  So 
`String::length` is a method reference that is equivalent to the lambda 
`(String s) -> s.length()`.  Even though the Javadoc says the length 
method has no arguments, users don't seem fazed by this at all.  So, 
doubling down on this seems like a good move.

> Bottom line: Static patterns, like static methods, are clunky to use and
> therefore instance patterns should be used wherever possible, even as
> complements to static factory methods.

I am surprised to find that this works so well, but I can find no flaw 
in your argument!  (But no, Remi, I don't think this obviates the value 
of having static patterns in the language, it just means we might use 
them less often.)   Very slick.