> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts@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
