Pattern matching -- background and design goals
mark
mark at io7m.com
Sat Apr 22 18:25:37 UTC 2017
On 2017-04-20T14:46:31 -0400
Brian Goetz <brian.goetz at oracle.com> wrote:
> I would like to start the discussion surrounding pattern matching with
> some motivation and goals. The design space here is enormous, and
> connected to so many other features, so bear with me as I try to
> linearize the story. I've posted a general introductory document on
> possibilities for pattern matching in Java here:
>
> http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html
>
Having digested both this and the switch document, I'm slightly
disappointed in that I can't find much to which I object. :)
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.
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? I remember
hearing in one of your previous talks that it's a design goal to at
least allow Optional and similar types to be updated in a way that's
backwards compatible with the old definitions. I'm not exactly sure
what this means.
M
More information about the amber-spec-experts
mailing list