New pattern matching doc

forax at univ-mlv.fr forax at univ-mlv.fr
Thu Jan 7 22:48:11 UTC 2021


> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 7 Janvier 2021 23:02:36
> Objet: Re: New pattern matching doc

>> 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.
There is a "does overriding pattern make sense" in the doc. 
But i see why you jump on what i've written, because you are right that in a case of the case method that represent the inverse of a constructor, there is no overriding. 

What i'm saying is that i see the methods that can be called by a pattern as a special member of class because they can not be called directly, but they are still methods. 
And the deconstructor is a particular case of case method the same way a constructor is a particular case of method, because you can not override them. 

>> 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.
It's because i think we don't need to single out deconstructor from the rest of the other methods that can be called by a pattern. 
As you said some case methods are total, some are not, this has nothing to do with this method being a deconstructor or not. 

>> 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.
Again, i think you are focusing too much on deconstructor by providing a syntax that only make sense on deconstructor. 

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


More information about the amber-spec-experts mailing list