Deconstructors a bit unintuitive?

[John Hendrikx]

I was reading 
https://github.com/openjdk/amber-docs/blob/master/eg-drafts/deconstruction-patterns-records-and-classes.md 
and wished to give some feedback.

I find the (possible) approach presented for deconstructors a bit 
counter intuitive, where parameters are treated as outputs for 
deconstructors. I think that an approach where it more closely matches 
the standard pattern of "<output> <function> <input>" would be more 
intuitive. The current approach instead looks very much like parameters 
that are passed by reference (pointers to those parameters) but without 
any indication (like "&" or "ref"), aside from the deconstructor 
keyword, that this is the case:

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

I find this quite jarring; overwriting (what looks like) a parameter 
with a new value never affected anything beyond the scope of the 
function. I realize that changing objects has effects beyond the 
function scope, but this was never the case for the parameter variables 
themselves.

Deconstructors in my opinion seem to be an almost natural fit for 
another, more general, language feature: multiple return values.  A 
deconstructor could then be nothing more than a normal method, or a 
static method with a special name (like constructors).

Just to clarify my point if the above didn't make sense, I think 
deconstruction could be a lot closer to current Java like this:

       // static construction and deconstruction
       Point p = new Point(x, y);
       x, y = Point(p);

       // static construction and deconstruction with named method
       Point p = Point.of(x, y);
       x, y = Point.from(p);

       // instance method
       Point p = p.translate(10, 20);
       x, y = p.deconstruct();  // potentially taking parameters to 
affect result

This would seem to be much closer to the inverse of construction.

The declaration of the unnamed deconstructor would be the reverse of a 
constructor:

       class Point {
            Point(int x, int y) { ... }

            (int, int) Point {
                 return this.x, this.y;
            }
       }

I suppose this has been considered and discussed before, and introducing 
something as generic as multiple return values in order to support 
deconstructors in this way may be a bridge too far, but perhaps my 
feelings on this topic may still contribute something to this feature.

--John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220922/b83a98bd/attachment.htm>