<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Sent: </b>Wednesday, April 3, 2024 2:48:40 PM<br><b>Subject: </b>Re: Member Patterns -- the bikeshed<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4" face="monospace">I would summarize your comments
below as: Let's throw the entire model in the garbage, and replace
it with something like Scala's "return an Optional<Tuple>"
instead.</font><font size="4" face="monospace"><br><br>
We've been discussing the model for several years; you've been
asking (and waiting patiently) for "when are we going to talk
about declaration syntax", and now that we're there, you want to
throw it all out and start over? </font></blockquote><div><br></div><div>My makeup job was too big so you do not recognize your model behind :)<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>There are two parts, the declaration part and the use-site part.<br data-mce-bogus="1"></div><div>Correct me if i'm wrong but apart the support of a method pattern with no prefix, we are in agreement here.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>For the declaration part, I think that<br></div><div> carrier(int x, int y) asCartesian()</div><div>is more readable than<br data-mce-bogus="1"></div><div> inverse () asCartesian(int x, int y)<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>The inverse notation is a leaky abstraction in a leat two cases<br></div><div>- when a modifier or an annotation is used. For an annotation, there is a notion of a target and the parameter target is at the wrong place,<br data-mce-bogus="1"></div><div>- when declaring a lambda, because in that case the parameters are not inversed.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Now, what i call a carrier type is what you call a list of bindings.<br data-mce-bogus="1"></div><div>In terms of syntax, I think it is important to put a name in front of that list of bindings, i've proposed "carrier" so we provide a name for that feature, it's easier when discussing about it it or google it.<br data-mce-bogus="1"></div><div>That does not change the fact that a method that returns a carrier is a special method because it requires at least a special erasure (because overloading), and a special reflection API,<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>But I hope, we will not cross the line and have to use new opcodes in the bytecode.</div><div>For me, a method that returns a carrier is something that can be desugared classical Java elements like an enum or a record is desugared to a class.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4" face="monospace"><br>
We've discussed how strategies that rely on "ask the user to
declare a record for every API point" feel clever for about five
minutes, but start to feel old quickly. </font></blockquote><div><br></div><div>yes, this is what you have to do actually if you simulate the feature with Java nowadays. Not, what you should have to do in the future.</div><div>And the idea is to do better, among other things, we want to suport overloading.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4" face="monospace"><br><br>
The "carrier" concept in your examples seems to be just another
way of reinventing multiple return -- with the added dis-bonus of
being like but not quite the same as records. We've been pretty
clear that "multiple return" is not the design center here.</font></blockquote><div><br></div><div>The idea behind a carrier is to let users define their binding list is a way that does not feel too strange, that why I propose to add a name/keyword in front of the binding list.<br></div><div><br data-mce-bogus="1"></div><div>And I do not know how you define what a binding list is but multiple return + components description is a good definition for me.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4" face="monospace"><br><br>
The use of ! for indicating totality is interesting, that's worth
thinking about.<br><br><br></font><br>
<div class="moz-cite-prefix">On 4/3/2024 6:21 AM, Remi Forax wrote:<br>
</div>
<blockquote cite="mid:407911070.46485631.1712139695181.JavaMail.zimbra@univ-eiffel.fr">
<div>I think that by not starting from the deconstructor, the
notion of inverse methods make less sense.</div>
<div>I think that the notion of carrier / carrier type is less
disruptive that the notion of member patterns.</div>
</blockquote>
<br>
<br><br></blockquote></div></div></body></html>