----- Mail original -----
> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "Guy Steele" <guy.ste...@oracle.com>, "amber-spec-experts"
> <amber-spec-experts@openjdk.java.net>
> Envoyé: Samedi 29 Août 2020 00:43:10
> Objet: Re: [pattern-switch] Totality
>>
>> It's not rare to add components to a sum type, by example a MouseEvent
>> is upgraded to add the number of mouse wheel scroll knobs.
>
> (later corrected to "product")
>
> To do that, you can't just blindly add a new component, because existing
> ctor calls will no longer link. If yesterday you had
>
> record Foo(int x, int y) { }
>
> then if you want to add a z, you have to:
>
> record Foo(int x, int y, int z) {
> Foo(int x, int y) { this(x,y, 0); }
> }
>
> and now old ctor sites will link.
>
> It's exactly the same with dtors; if you add a component, you have to
> explicitly provide the dtor with the old descriptor.
I'm challenging that view,
first the equivalent of a destructor is not a constructor at least not a plain
one, it's more like the canonical constructor, the one that ask the names of
the parameter to be in a certain order, i.e. the one that allow to creates an
object from names + values instead of position + values.
In that model, you don't need several deconstructors, you only need one because
the runtime of the pattern matcher will only extract the part that is useful by
names instead of by positions.
When you specify a destructuring pattern, the compiler use the positional order
to match the component but at runtime, this is not needed.
This is basically the model used to serialize/deserialize a record.
>
>> in my opinion, a cascade of if ... instanceof and a switch on types
>> should have the same constraints
>
> It's a good intuition, but can you be specific about what constraints
> you are talking about ?
see the mail of Guy.
Rémi
