<html><head>
<style id="css_styles">
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: center; '], li[style='text-align: right;'], li[style='text-align: right; '] { list-style-position: inside;}
body { font-family: 'Segoe UI'; font-size: 12pt; }
.quote { margin-left: 1em; margin-right: 1em; border-left: 5px #ebebeb solid; padding-left: 0.3em; }
</style>
</head>
<body>I was reading <a href="https://github.com/openjdk/amber-docs/blob/master/eg-drafts/deconstruction-patterns-records-and-classes.md">https://github.com/openjdk/amber-docs/blob/master/eg-drafts/deconstruction-patterns-records-and-classes.md</a> and wished to give some feedback.<div><br /></div><div>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:</div><div><br /></div><div> public deconstructor Point(int x, int y) { x = this.x; y= this.y; }</div><div><br /></div><div>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.</div><div><br /></div><div>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). </div><div><br /></div><div>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:</div><div><br /></div><div> // static construction and deconstruction</div><div><span> Point p = new Point(x, y);</span></div><div> x, y = Point(p);</div><div><br /></div><div> // static construction and deconstruction with named method</div><div><span> Point p = Point.of(x, y);</span></div><div> x, y = Point.from(p);</div><div><br /></div><div> // instance method</div><div> Point p = p.translate(10, 20);</div><div><span> x, y = p.deconstruct(); // potentially taking parameters to affect result</span></div><div><br /></div><div>This would seem to be much closer to the inverse of construction.</div><div><br /></div><div>The declaration of the unnamed deconstructor would be the reverse of a constructor:</div><div><br /></div><div> class Point {</div><div> Point(int x, int y) { ... }</div><div><br /></div><div> (int, int) Point {</div><div> return this.x, this.y;</div><div> }</div><div> }</div><div><br /></div><div>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.</div><div><br /></div><div>--John</div><div><br /></div></body></html>