> De: "Brian Goetz" <brian.go...@oracle.com> > À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Mercredi 12 Août 2020 22:44:04 > Objet: A peek at the roadmap for pattern matching and more
> Several folks have asked that I sketch out a little more of the roadmap for > pattern matching, so that we can better evaluate the features being discussed > now (since, for example, the semantics of pattern matching are heavily > influenced by nested patterns.) > I've checked into two drafts which are VERY ROUGH, but which correspond to the > next two logical increments after patterns in switch. > Deconstruction patterns: > [ > https://github.com/openjdk/amber-docs/blob/master/eg-drafts/deconstruction-patterns-records-and-classes.md > | > https://github.com/openjdk/amber-docs/blob/master/eg-drafts/deconstruction-patterns-records-and-classes.md > ] > This document outlines the semantics of deconstruction patterns and nested > patterns, and declaration of deconstructors in classes. In the code: public deconstructor B(int a, int b) { super(var aa) = this; a = aa; b = this.b; } i believe the first line should be A(var aa) = super; I know that you have consider something like this, but i prefer making the deconstructor a method returning a tuple at Java level, to be closer to the JVM level. So a syntax more like class Point { int x; int y; (int x, int y) deconstructor { return (this.x, this.y); } } Conceptually, it's also more like the reverse of a constructor, a constructor takes the values from the stack to move them to the heap, a desconstructor takes the value from the heap and move them to the stack. > (There are some teasers for related features, mostly to put these in context, > but I don't want to get distracted on those features until these are nailed > down, so take them as merely context.) Rémi
