<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <blockquote type="cite" cite="mid:969518960.110944933.1706092683452.JavaMail.zimbra@univ-eiffel.fr">
      <pre class="moz-quote-pre" wrap="">Hello,
I agree until the section 'Recovering static factory arguments', because at that point, it's the tail waging the dog.</pre>
    </blockquote>
    <br>
    I'm not sure which is tail and which is dog here, but it sure sounds
    like you are saying "the entire premise of this exercise is flawed,
    so we should throw all this work in the trash."  (After all, you
    only got two paragraphs into the motivation before declaring
    divergence.)  I hope you're not saying that, but let's try to be
    more clear about what you are saying?<br>
    <br>
    <blockquote type="cite" cite="mid:969518960.110944933.1706092683452.JavaMail.zimbra@univ-eiffel.fr">
      <pre class="moz-quote-pre" wrap="">In this section you introduce a new syntax with little justification ("it makes sense") which should not a big problem if it was not your way to justify the introduction of pattern method being static, which are static only because the syntax you have chosen looks like static calls.</pre>
    </blockquote>
    <br>
    If you're talking about the use-site syntax, we've been using these
    examples for years, so it is a little surprising to hear an
    objection now.  But let's back up and go over the motivations for
    this broader effort.  <br>
    <br>
    Java offers many means for aggregation, both formal (constructors)
    and informal (factories, builders, etc), and may offer more in the
    future (e.g., collection literals).  Further, these mechanism of
    aggregation compose freely; I can say <br>
    <br>
        Optional<Shape> os = Optional.of(Shape.redBall(1));<br>
    <br>
    without Foo and Optional having to coordinate in anyway.  <br>
    <br>
    Java offers no formal means for disagreggation, instead dumping it
    in the user's lap to write ad-hoc APIs such as getters.  To ask
    "does os contain a red ball of radius 1", we would currently have
    to:<br>
    <br>
        Shape s = os.orElse(null);<br>
        boolean isRedUnitBall = s != null<br>
                               && s.isBall()<br>
                               && (s.color() == RED)<br>
                               && s.size() == 1;<br>
        if (isRedUnitBall) { ... }<br>
    <br>
    The flaws here are many: I have to use a different API to take apart
    Optional as Shape, the two do not compose, and the take-apart code
    looks nothing like the put-together code.  This adds cognitive
    friction both when reading and writing, and is error-prone.  <br>
    <br>
    So, goals:<br>
    <br>
     - It should be as easy to take apart as to put together<br>
     - It should be as easy to compose take-apart operations as it is to
    compose put-together operations<br>
     - Taking apart should _look like_ putting together<br>
    <br>
    I don't think you are really objecting to this last bullet, but it
    sure sounds like you are.  <br>
    <br>
    To address your question of "why do we like this use-site pattern
    syntax for static patterns", the answer has been stated over and
    over: taking apart should look like putting together, because taking
    apart asks the Pattern Question about a particular form of putting
    together.  <br>
    <br>
        case Point(int x, int y):<br>
    <br>
    asks "could this object have come from `new Point(x, y)` for some
    (x, y)."  But since not all classes expose constructors, we should
    be able to ask the same question about a corresponding factory form
    as well (and questions about de-constructor and questions about
    de-factory *must* compose with nesting.)  The composed:<br>
    <br>
        case Optional.of(Shape.redBall(1)):<br>
    <br>
    asks the Pattern Question again: Could this object have come from
    `Optional.of(Shape.redBall(1))`.  <br>
    <br>
    <blockquote type="cite" cite="mid:969518960.110944933.1706092683452.JavaMail.zimbra@univ-eiffel.fr">
      <pre class="moz-quote-pre" wrap="">I think that choosing a syntax at that point is premature given the semantics is still in flux, especially if that syntax is used as a justification to say that pattern methods are static (*). At that point, it's a trap.</pre>
    </blockquote>
    <br>
    Whoa, did you *read* the document?  There's nothing inherently
    static about "pattern methods" (if we want to call them that), any
    more than there is anything inherently static about methods.  I
    think you should go back and read the whole document again, and if
    you still think that pattern methods are "static", let's address
    that conception directly before proceeding?<br>
    <blockquote type="cite" cite="mid:969518960.110944933.1706092683452.JavaMail.zimbra@univ-eiffel.fr">
      <pre class="moz-quote-pre" wrap="">In case of method pattern, it's an issue because it means that if you have a pattern method on an interface, an implementation cannot override it. </pre>
    </blockquote>
    <br>
    Incorrect (and I think this should have been clear both from this
    document and from the earlier "Patterns in the Object Model"
    document.  Just as an interface can declare both static and instance
    methods, it can have both static and instance patterns.  Instance
    patterns are overridable, can be abstract, etc.  <br>
    <br>
    <blockquote type="cite" cite="mid:969518960.110944933.1706092683452.JavaMail.zimbra@univ-eiffel.fr">
      <pre class="moz-quote-pre" wrap="">Here is an example using the syntax you propose, let say I want to do the inverse of Map.entry(), if write an inverse pattern method inside Map then the only way write it is to use the getters getKey() and getValue().</pre>
    </blockquote>
    <br>
    We are getting far ahead of ourselves, but if you wanted this
    behavior to be overridable, but still added retroactively, you could
    write a default pattern.  But given how many layers of
    mis-assumption we have here, let's prune this particular branch of
    discussion until it is clear you understand what is being proposed. 
    <br>
    <br>
    <br>
    <span style="white-space: pre-wrap">
</span><br>
  </body>
</html>