Comment on JEP 305
Brian Goetz
brian.goetz at oracle.com
Wed Jan 8 15:47:38 UTC 2020
> Specifically, I want to share my feedback regarding the "Pattern Matching for instanceof" feature.
Actually, your feedback is not on the feature, but on the stewardship
process itself -- you wish we had done a different feature instead.
Which is a valid reaction -- everyone has their own preferences for what
we should do -- but unless you are the first person to suggest "have you
considered flow typing" (for which you would be many years late), such
feedback is not all that helpful. We looked carefully at flow typing,
and found it wanting.
Tagir well-covered the two main reasons why flow typing is a poor
alternative to pattern matching:
- Adding flow typing to the language could change the meaning of
(that is to say, break) existing code;
- Flow typing is a much weaker and less general feature than pattern
matching; it's just not obvious from reading JEP 305, because this is
merely the first installment of pattern matching and so many of the
examples look like they could be addressed by flow typing.
The question of "why not 'just' do flow typing" was also addressed in
the public document:
http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html
Flow typing is not a _bad_ feature, but it's a pretty weak one; it
basically works only for one thing. When you fold in the compatibility
risk, that's a pretty automatic no.
> There is no reason given for why the variable should be renamed
There are several misconceptions buried in this claim. First, that it
is a renaming at all; it is not, it is the declaration of a new
variable, with its own scope (and mutability). But more importantly,
the operand of an instanceof expression (or a switch) need not be a
_variable_; it can be any expression. You're letting the "Flow typing
is all I will ever need" concept prevent you from understanding what
pattern matching actually is.
As to your main gripe -- having to come up with a new variable name --
it has been (publicly) discussed that the binding variable in a type
pattern at the top level of an instanceof/switch whose operand is a
variable declare a variable name _could be_ the same as the operand:
if (x instanceof Foo x) { ... }
where the inner `x` would shadow the outer. This is a possible future
enhancement -- there's nothing intrinsically wrong with it -- but if you
look at the parade of qualifiers I had to add to my description above,
you get an inkling of why this isn't something we'd grab at out of the gate.
More information about the amber-dev
mailing list