New [draft] JEPs for Pattern Matching
Stephen Colebourne
scolebourne at joda.org
Thu Dec 13 23:37:21 UTC 2018
On Thu, 13 Dec 2018 at 01:33, Brian Goetz <brian.goetz at oracle.com> wrote:
> So, let’s back up. Almost all of your note was about a solution, but what’s missing is what’s motivating you to propose this particular solution. It’s almost always more useful to share your perception of a _problem_ than a proposed solution. (Maybe the problem isn’t really a problem, in which case the solution isn’t needed. Or maybe theres a better solution, but without a shared understanding the problem, we can’t really evaluate your solution.) You alluded to the possibility of writing obtuse code — but, even if obtuseness were objective, the possibility that someone might write confusing code is not a reason to arbitrarily constrain the language.
>
> So, let’s start over. What _problem_ you are concerned about?
I can see plenty of examples and motivating use cases for a single
pattern test in an if statement, with optional when and optional else.
The use cases for combining patterns, or negating them, seems weaker -
it doesn't happen in switch AFAICT (certainly I've never seen an
example where it has been proposed).
I think its right to question whether there really is enough
motivating use case to justify patterns *everywhere*, which is what is
implied by making them boolean expressions. Especially as the
implication of doing so is a whole heap of complicated rules around
the scope of the new variable.
I assume the following is either pointless or a compile error:
boolean isString = obj instanceof String s;
What about this - is s in scope in the braces?:
while (obj instanceof String s) { ... }
Or this - pointless, or error?:
list.stream().filter(obj -> obj instanceof String s);
Pattern-tests as arbitrary boolean expressions opens up a whole range
of possibilities where the rules may not be instantly obvious. Maybe
its the right direction for Java, but I haven't seen anyone
questioning the implications or the need beyond the simple/obvious
examples. No one doubts the boolean expression approach is more
expressive, but I question the assertion that it has less complexity.
As a separate, and syntax only point, I think `case` is more readable
and more intuitive than extending `instanceof` whichever semantics are
adopted, in that a pattern is always preceeded by case (and also
instanceof implies a type on the RHS but not all patterns are types,
right?).
Stephen
More information about the amber-dev
mailing list