New pattern matching doc

[Brian Goetz]

>
> Hi Brian,
> i'm glag that "deconstructor" can now be virtual.

Can you point to where in the doc you got that idea?   A deconstructor 
is the dual of a constructor.   A constructor is not a virtual member, 
nor a static member; it takes a receiver, but is not inherited and 
cannot be overridden.  Deconstructors are exactly the same way.  There 
will be other kinds of patterns -- analogous to static and instance 
methods -- but they're different from deconstructors.  This doc alludes 
to their existence, but doesn't yet give examples.  That's for another doc.

>
> I think there is a missing discussion about what a case method can 
> return, it can return something saying no match, it can return 
> something saying there is a match and here are the values.

No (but I understand why you assumed this, you are skipping ahead to the 
exciting part of the story.)  Some patterns are _total_ (always match 
target of a given type) and some are _partial_ (imposing additional 
conditions on matching).  I am currently assuming "deconstruction 
patterns are always total" (this is probably only 99.99% true, but a 
reasonable simplifying assumption) so there's no provision for saying 
"nope, this does not match" _for deconstructors_.   The other kinds of 
declared patterns (static and instance patterns) surely need some way of 
saying "no, it didn't match" (and there's many options for how to 
surface this), and while this document alludes to the existence of these 
patterns, there's more coming.  This is not the "mechanics" document, it 
is this "10,000 foot view of the object model" document.

> One question is how the values are associated to the bindings, in the 
> pattern, you have a notion of order, i.e. Point(var x, var y), x is 
> the first binding and y the second, but in your proposed syntax, there 
> is no notion of order, you associate a name to a value.

Correct.  There are many different ways to model this.  (I know you're 
partial to the "return a tuple" model.)  In the examples I gave for 
illustrative purposes, I have turned the knob mostly towards the 
"imperative", to the point where a deconstructor body is almost 
literally the mirror image of a constructor body.  There are other ways 
to do it, and there's a conversation to be had there, but that wasn't 
the conversation I was trying to elicit with this document.  This 
document is entirely about "what is the role of a pattern in the 
language and object model", because, if we can't agree on that, then the 
syntactic concerns are irrelevant.

There's more coming which will dive into the mechanics and user model 
that you'd like to talk about here, but I'm still not quite ready for 
that, not until we are on the same page with the big-picture questions.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210107/d125a10e/attachment.htm>