<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 6:30:33 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:405841076.113655778.1706288871551.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>
(It could also be a default pattern; works the same as
default methods.) The implementation in emptyList always
fails. The implementation in ArrayList might look like:<br>
<br>
public __inverse List<T> withElement(T element) {
<br>
if (that.size > 0)<br>
_yield that.elements[0];<br>
}<br>
<br>
Now, implementing this guy gets tricky, since we have two
context variables which are both of the same type,
ArrayList<T>. (Maybe we have to explicitly use a
covariant "override" here; TBD.) </blockquote>
<div><br>
</div>
<div>I do not think allowing covariant override is sound.
Because if the method is unbound, yes, 'this' and 'that' are
the same object at runtime, but if 'this' is bound, these
are two differents objects so no covariant override should
be allowed.</div></div></div></blockquote></blockquote><div><br></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;"><blockquote cite="mid:405841076.113655778.1706288871551.JavaMail.zimbra@univ-eiffel.fr"><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><div><br data-mce-bogus="1"></div>
</div>
</div>
</blockquote>
<br>
Please, let's sync on the model before we turn to syntax. <br>
<br>
<blockquote cite="mid:405841076.113655778.1706288871551.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div>If the section "Pattern
resolution" is rewritten in terms of bound and unbound
methods, I agree<br>
</div>
</div>
</blockquote>
<br>
OK, so where I think we are is:<br>
<br>
- We basically agree that each of { deconstructor, static pattern,
instance pattern } are useful and have valid use cases, and to the
extent possible, we should be guided by the duality with {
constructor, static method, instance method }</blockquote><div><br></div><div>yes, for the former, for the latter, the syntax favor the relationship between the pattern and the corresponding method declaration over the consistency of the declaration and the body of the method. So I suppose it depends on how the body is specified, nevertheless it's an interresting idea.<br></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>
- 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 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>
- 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 data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div><div data-marker="__QUOTED_TEXT__">Rémi<br data-mce-bogus="1"></div><div data-marker="__QUOTED_TEXT__"><br data-mce-bogus="1"></div></div></body></html>