<div dir="ltr">I think what has been proposed so far is powerful enough to perform that task <i>if</i> there is an intermediate object in the mix.<div><br></div><div><font face="monospace">if (<br>    // Assuming a dual pattern for JsonString.of and the SAP<br>    // strategy outlined in the doc<br>    json instanceof index(0, JsonString::of).decode(var firstName)<br>) {<br><br>}</font></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, May 21, 2025 at 1:26 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <p><br>
    </p>
    <div>On 21/05/2025 18:06, Paul Sandoz wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>It was a design choice to be consistent with each json value having an 
X, accepting X in on construction and producing X out (notionally) on 
deconstruction, which leans into pattern matching. Definitely pros/cons 
to that e.g., we could instead make JonObject implement Map, or do as 
you suggest [*], both of which adjust how one reasons about the X in and
 X out.</pre>
    </blockquote>
    <p>I agree with this. When I wrote, I thought that it might be
      possible to address some of these use cases using instance pattern
      declaration on the array class (e.g. having an instance pattern
      that extracts the i-th element of a JSONArray) -- but the instance
      pattern proposals we have discussed so far [1] are not powerful
      enough to model that use case.</p>
    <p>Maurizio</p>
    <p>[1] -
<a href="https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns" target="_blank">https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns</a><br>
    </p>
  </div>

</blockquote></div>