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