<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>Friday, January 26, 2024 7:11:29 PM<br><b>Subject: </b>Re: Towards member patterns<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;"><br>
<blockquote cite="mid:1527973645.113720588.1706291692888.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<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;"><br>
- We basically agree that at the use site, we have all the
qualification modes we have with methods { constructor
qualified with package, static member qualified with type,
instance member qualified with receiver } , and possibly, an
additional mode of "instance qualified by type" </blockquote>
<div><br>
</div>
<div>for me the special mode is more 'instance member
qualified with receiver' but yes,<br>
</div>
</div>
</div>
</blockquote>
<br>
I think you'll find once you start writing code with it that the
receiver-qualified version is more common than you think. And, if
we only could have one, it has to be the receiver-qualified one,
since you can get to the "unbound" version by specifying the
receiver explicitly (use the match candidate as an explicit
receiver), but you can't go the other way -- if all you have is
unbound, you can't do regular expressions, you can't do type
classes, you can't do anything virtual where the pattern operates on
something other than itself. So receiver-qualified is the
"primitive" and the other is a convenience syntax that we can layer
on top of it if we need. </blockquote><div><br></div><div>By special mode, i mean having the bound being speicifed explicitly even if it is this.<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;"><br>
<br>
<blockquote cite="mid:1527973645.113720588.1706291692888.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div>
<div><br>
</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;"><br>
- The details of the last one are not fully worked out,
that's fine<br>
- The details of exhaustiveness are not fully worked out,
that's fine<br>
<br>
Is that about right?<br>
</blockquote>
yes,
<div><br>
</div>
<div>and there is also how to send parameters to the pattern
method (and if this is something we should support) that can
be added to that list.<br>
</div>
</div>
<div><br>
</div>
</div>
</blockquote>
<br>
This one is interesting. I was convinced at first we needed it, but
I now think we can do without it (in this form), and we can get the
effect of it in a more organic way. <br>
<br>
In any case, glad that we're on the same page. More docs coming.</blockquote><div><br></div><div>It just occurs to me that there is another hurdle to figure out, annotations.<br data-mce-bogus="1"></div><div>Annotations are not really reversible, the way you specify annotations on a return type (on the method) and on parameter types is different, it's not the same @Target.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>If you have an annotation that log the return value (a classical AOP exercise), for an inverse method, do you put it on the parameters (in that case where) or on the return type knowing that in fact it's a parameter ?<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>And you have the explicit "this" (to be able to annotate it), which on an inverse method is a true parameter unlike the others.<br data-mce-bogus="1"></div><div> class Foo {<br data-mce-bogus="1"></div><div> inverse List<String> bar(Foo this, Baz baz) {<br data-mce-bogus="1"></div><div> ...<br data-mce-bogus="1"></div><div> }<br data-mce-bogus="1"></div><div> }<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>regards,<br></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></div></body></html>