Deconstructor return type as record ?

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 2 Janvier 2020 22:22:44
> Objet: Re: Deconstructor return type as record ?

> There are at least two questions here, one having to do with records, the other
> having to do with pattern matching.

> Recall, in Lambda, how we chose to do nominal function types (functional
> interfaces) rather than structural ones. Records make a similar choice --
> rather than doing structural _tuples_, we choose to do nominal ones. So the
> question you are raising becomes: is there an equivalent of "SAM conversion"
> for records, as there was for lambdas? In your example, you posit one example:
> that an expression of the syntactic form (x,y) can be converted to a record of
> the right shape.

> I think the answer here is "we're still not sure". It's been an idea that's been
> sitting around in the idea pile for a while, but so far I've not been thrilled
> with some of the ways we might have exposed it. Ideas like this are
> superficially attractive, but they don't go very deep; they only optimize the
> instantiation. And, while you could say the same for lambdas vs inner classes,
> in the tuple-vs-constructor example, the difference is much smaller than it was
> for lambdas vs inner classes (both syntactically and semantically.) So I think
> this is indeed sugar, and the sugar goes on last.
It depends if you teach the compiler/VM to consider the record created inside the deconstructor to be an inline even if it is not declared as such. 
In that case, a deconstructor is close to a zero cost abstraction. 

> As to the pattern matching aspect, I know you've been wanting to have the "what
> does a deconstructor look like" discussion for a long time, but we're still not
> ready to have that discussion. I promise, these requests have not been
> forgotten, and we'll bring it up when we're ready to!
yes, i would like to move on that subject to have a better idea of the input/output of the pattern matching in term of data. 
And i think that instead of try to create a design that encompass every cases before trying to play with it, i think we should try to do simple pattern matching with extraction and see how we can grow from that. 

Rémi 

> On 1/2/2020 4:08 PM, Remi Forax wrote:

>> We have introduce records because it's a simple abstraction to extract values
>> when doing the pattern matching.
>> Given that records are named tuples, does it means that a deconstructor is just
>> a classical method with no parameter and a record as return type ?

>> public class Point {
>>   private final double rho, theta;

>>   public Point(double x, double y) {
>>     rho = Math.hypot(x, y);
>>     teta = Math.atan(y / x);
>>   }

>>   public record RectangularPoint(double x, double y) { }
>>   public RectangularPoint deconstructor() {
>>     return new RectangularPoint(rho * Math.cos(theta), rho * sin(theta));
>>   }
>> }

>> and with a little syntactic sugar to see any tuples as a Record (like we see any
>> lambdas as a functional interface)
>>   public RectangularPoint deconstructor() {
>>     return (rho * Math.cos(theta), rho * sin(theta));
>>   }

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