<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>