A peek at the roadmap for pattern matching and more

[forax at univ-mlv.fr]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Guy Steele" <guy.steele at oracle.com>, "Brian Goetz" <brian.goetz at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at 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, forax at 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