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 !
