<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 9/22/2022 9:37 AM, John Hendrikx
wrote:<br>
</div>
<blockquote type="cite" cite="mid:em069c4c4e-e41f-4e5b-bde6-6a7ae85d86cf@a732b55b.com">
<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>
I was reading <a href="https://github.com/openjdk/amber-docs/blob/master/eg-drafts/deconstruction-patterns-records-and-classes.md" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/amber-docs/blob/master/eg-drafts/deconstruction-patterns-records-and-classes.md</a> and
wished to give some feedback.</blockquote>
<br>
I appreciate the feedback, but I'm going to ask you hold it for a
few reasons:<br>
<br>
- This feature isn't really even really under discussion yet - the
document shown was merely an illustrative sketch, and no substantive
discussion has been had yet;<br>
- Your concerns are mostly with the illustrative example syntax
shown in that document, which should not be taken as a serious
proposal. (One of the trouble with such documents is that you have
to show *something*, but then people will immediately assume "so
this is the final syntax" and commence arguing.) <br>
- The syntax concerns of deconstructors are coupled to more complex
forms of pattern declaration, whose considerations and requirements
may not yet be obvious and are not considered in that document. <br>
<br>
Basically, that document was attempting to illustrate the dualities
between constructors and deconstructors, and didn't want to try to
do more, but of course it is hard to visualize these things without
a code sketch, and hard to treat such code sketches for what they
are. <br>
<br>
I'll try to speak a bit to your general conceptual issues, bearing
in mind the constraints of the above.<br>
<br>
<blockquote type="cite" cite="mid:em069c4c4e-e41f-4e5b-bde6-6a7ae85d86cf@a732b55b.com">
<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. </div>
</blockquote>
<br>
To some degree, declaring patterns is going to be uncomfortable
somehow no matter what we do. Its not obvious from the examples in
the document, which were focused on a different aspect, but in
generality patterns can have full argument lists of *both* input
parameters and output bindings. They simply will not fit cleanly in
the "N in, one out" model of methods. So there is going to be
something counterintuitive somewhere, and the solution is likely to
involve some degree of extending our mental model about executable
members. <br>
<br>
<blockquote type="cite" cite="mid:em069c4c4e-e41f-4e5b-bde6-6a7ae85d86cf@a732b55b.com">
<div>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>
</blockquote>
<br>
Your point is correct that the *position* of the binding list in the
declaration is unnecessarily confusing, because it is where you
would expect the parameters to be. As it turns out, there are other
reasons why this particular positioning has issues, but I'm not
going to repeat the mistake by showing a more recent sketch, so
we'll just have to wait for a "serious" proposal before continuing
the discussion. <br>
<br>
<blockquote type="cite">
<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>
</blockquote>
<br>
The "multiple return" interpretation is indeed one that springs
easily to mind as a first thought, but it turns out to run out of
gas before it gets where it needs to go. (See "Isn't this just
multiple return" in
<a class="moz-txt-link-freetext" href="https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/pattern-match-object-model.md">https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/pattern-match-object-model.md</a>
for one of the multiple reasons why I don't want to go in this
direction.) <br>
<br>
The issues outlined in that section illustrate where this approach
runs out of gas: it would only work with unconditional patterns.
Deconstructors are unconditional, but it is a short hop to patterns
that are the dual of, say, `Optional.of(v)`, and then treating
destructuring as merely "invoking a multiple return method" falls
apart because it has no way to express the conditionality. And
having a separate syntax for "invoking" conditional and
unconditional patterns carries its own problems. <br>
<br>
Which brings us to my initial statement, which is that patterns are
going to require extending our mental models about executable
members. It is probably better to discuss what that model is
first. <br>
<br>
<br>
<br>
<br>
</body>
</html>