A peek at the roadmap for pattern matching and more

[forax at univ-mlv.fr]

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

> On Aug 13, 2020, at 12:39 PM, Guy Steele < [ mailto:guy.steele at oracle.com |
> guy.steele at oracle.com ] > wrote:

>> 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. (Granted, these variables have a somewhat new
>> and mysterious existence and character.)

> And if this mysterious character were something completely unrelated
> to any other part of the Java language, I’d be more inclined to admit
> that maybe the missing primitive is some sort of tuple. It might have
> to be given a status like that of Java arrays to avoid the infinite regress
> problem you point out.

> BUT, when I stare at a block of code that is setting some named/typed
> variables, where those variables must be DA at the end of the block,
> and then they are to be available in various other scopes (not the
> current scope, but other API points), THEN I say, “where have I
> seen that pattern before…?” There is ALREADY a well-developed
> part of the Java language which covers this sort of workflow
> (of putting values into a set of required named/typed variables).

> Of course, it’s a constructor, especially when the object has final
> fields that are checked by the DA/DU rules. Now, maybe those rules
> aren’t everybody’s favorite; they are complicated to learn. But
> Java programmers do learn them. How about if we give them
> additional rewards for having learned then? Instead of asking
> them to learn yet another sub-language (tuples-for-deconstructors)
> that is completely different?

> (Yes, I’m partial to DA/DU because those are my rules, for better
> or worse. Maybe Remi’s going to say something about a sunk cost
> fallacy. But I think the rules are useful and, with an IDE’s help,
> intuitive. And they can do more for us now. Let’s double down
> on them.)

That's true, most Java devs already knows how to write constructors using DA/DU rules, but we don't need those complex rules in a deconstructor. 
DA/DU rules exist because we want to be able to see the instance not yet fully initialized in the constructor, so users can write things like a circular list. There is no such need for a deconstructor, the result is always a tree, not a graph. 

A deconstructor is just a method with several return values, which is the dual of the constructor that takes several parameter values. 

For me it's like having a complex lock on the front door and wanting to have the same mechanism on the opposite side of the front door (to go out) because you already know how to unlock the front door. 

[...] 

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