Pattern matching -- background and design goals
brian.goetz at oracle.com
Sat Apr 22 19:04:20 UTC 2017
> Having digested both this and the switch document, I'm slightly
> disappointed in that I can't find much to which I object. :)
Patience! I'm sure I'll come up with something objectionable eventually.
> The new scoping rules are a little spooky with regards to reading
> comprehension, but I think they're a fairly pragmatic choice in the
> absence of "let" expressions in the language.
The secret to understanding these rules is that they are the
definite-assignment rules in disguise. They basically say that a
binding variable is made-available-to any expression / statement in
which it would be definitely assigned. The weird thing about them is
that they don't conform to traditional block scoping; the set of
expressions/statements into which a given pattern may inject bindings
does not form a traditional block. You could call this "flow-based
> I'm curious though, based on the given Optional example, if the
> intention is to design things in such a way that values of the existing
> Optional class could be matched upon (with exhaustiveness checks)
> without anyone having edited the definition of Optional?
Not quite. But it doesn't require deep intrusion (like changing the
implementation to a Some/None decomposition); merely the adding of
matchers (which I claim are some sort of class member, so this is like
adding new methods) for Optional.of() and Optional.empty(). What that
doesn't give us is exhaustiveness -- but at least it gives us a path to
back-fitting existing classes with ctors/factories to play in
destructuring-land without major surgery.
More information about the amber-spec-observers