> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@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
