----- Mail original ----- > De: "John Rose" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "Brian Goetz" <[email protected]>, "amber-spec-experts" > <[email protected]> > Envoyé: Jeudi 13 Août 2020 01:36:41 > Objet: Re: A peek at the roadmap for pattern matching and more
> On Aug 12, 2020, at 4:28 PM, Remi Forax <[email protected]> wrote: >> >> >> 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. > > To be closer to the JVM level we should number our variables, not name them. > That is, if being closer to the JVM level were so important as to prefer > positional notations to name-based notations. I was thinking about closer to the generated classfile, not closer to the VM internals. > > One reason to avoid tuples is we’d have to reify them more thoroughly in the > language, and that seems like busy-work. It depends if tuples are reified by the VM or not. > > The more important reason to avoid tuples is they don’t have named components, > and the stuff we are looking at these days with records, constructors, and > deconstructors is *all about names*. yes, a tuple as a type is a structural type, if we use the now classical move of using a nominal type + some inference rules to represent the type of a tuple, the record class is a tuple type, so yes it has names the same way an abstract method of a functional interface has a name. > > — John Rémi
