> De: "Guy Steele" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "Brian Goetz" <[email protected]>, "amber-spec-experts" > <[email protected]> > 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:[email protected] | [email protected] ] >> 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
