----- Mail original ----- > De: "John Rose" <john.r.r...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Guy Steele" <guy.ste...@oracle.com>, "Brian Goetz" > <brian.go...@oracle.com>, "amber-spec-experts" > <amber-spec-experts@openjdk.java.net> > Envoyé: Vendredi 14 Août 2020 01:24:13 > Objet: Re: A peek at the roadmap for pattern matching and more
> On Aug 13, 2020, at 4:11 PM, fo...@univ-mlv.fr wrote: >> >> For me it's like having a complex lock on the front door and wanting to have >> the >> same mechanism on the opposite side of the front door (to go out) because you >> already know how to unlock the front door. > > Ow! Tough crowd. > > As you may have noted from my previous note, I’m > also concerned with managing, not single or double > or triple doors, but cases where there are too many > doors to go through all at once. This is where languages > add optional and named arguments. And once having > done so, I do admit that we could use such a new thing > profitably to manage wide multi-component data flows > both in and out of methods, if the symmetry argument > holds. And we could leave constructor blocks where > they always have been, in a corner. > > My proposals double down on the *asymmetric* > way Java delivers multiple values out of blocks, > compared to how they are sent into blocks by > position-argument-to-parameter binding. > > Brian’s point about symmetry is that it can be > a siren song: You put tuples in one place for > symmetry (with argument lists) and suddenly > you risk having a new kind of value, neither > primitive nor class nor array. (Arrays are the > old tuple; you really want to do that again?) > Tuples incur technical debt which makes > the symmetry proposal expensive, which is > why we are looking at other options as well. I'm a little disappointed by the current discussions, when Brian announced that a record will be immutable, I was flabbergasted how brilliant the idea was because not only you can use a record and do directly pattern destructuring on it but also you can use it as an anonymous carrier of values to transfer the values from a plain old class to a representation you can do destructuring on it. It seems that that plan has been lost at some point. An anonymous record is not a tuple, it's a plain Java class from the VM POV, so not a new kind of value (apart from the fact that it will be an inline most of the time) so i don't think it's a risky move. > > — John Rémi
