A peek at the roadmap for pattern matching and more

[forax at univ-mlv.fr]

> De: "Guy Steele" <guy.steele at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 13 Août 2020 21:39:33
> Objet: Re: A peek at the roadmap for pattern matching and more

>> On Aug 13, 2020, at 9:06 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
>> wrote:

>> . . .
>> ok, let's take a step back because i think the current proposal has fall in a
>> kind of local maximum in term of design.

>> We want a destructor, a destructor is a method that returns a list of values the
>> same way a constructor takes a list of parameters.
>> The way to represent that list of value is to use a record.

> While I agree that this sort of approach can be made to work, I have to say it
> is philosophically puzzling to say that the way to destruct (or deconstruct) an
> object is to take values from the relevant fields and then package them up in
> some other object! Superficially, at least, it seems like this approach leads
> to an infinite regress.

We hope most of these records to be inline types, (see the first sentence about the translation stategy) , so they are box in term of Java syntax but are more like immutable compounds of values at runtime. 

> Whereas I can more easily understand that the job of

> public deconstructor Point(int x, int y) {
> x = this.x;
> y = this.y;
> }

> is to take values out of the object “this” and put them into separate
> _variables_, not a new object.

If i am one of my students, either i will not understand understand why assigning x and y change something, or i will declare x and y final because StackOverflow says you should do that for every methods. 

> (Granted, these variables have a somewhat new and mysterious existence and
> character.)

yes it's full of magic. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200813/5cac55f2/attachment.htm>