<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Is it possible to solve this issue by making Java support invokeDynamic syntactically?</div><div dir="ltr">Users can provide their own helper classes similar to java.lang.runtime.ObjectMethods to synthesize methods.</div><div dir="ltr"><br></div><div>Glavo</div></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Dec 5, 2024 at 11:16 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@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>
    <br>
    <br>
    <br>
    <div>On 12/5/2024 4:34 AM, vab2048 wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>Hi Amber team,

I was wondering about the future of two different features and thought I would just ask the mailing list.

The first feature: deriving instances. 

Haskell allows type declarations to derive instances for certain type classes (Eq, Ord, Enum, Bounded, Show, and Read).

Is it possible to get some sort of equivalent for java classes which would allow us to specify to the compiler to auto derive some code. I am thinking about easily auto-generating a toString, equals, hash code etc? We already have a form of this for records, and so bringing it to classes would make a logical next step. </pre>
    </blockquote>
    <br>
    The strict equivalent of this is records: in Haskell, you don't get
    any control over how to derive type classes such as Eq and Show, and
    similarly for records: the one the compiler gives uses all the
    state.  So in some sense, mission accomplished.  But that's not
    really what you're asking.  What you're asking is for an _arbitrary
    class_ -- not just a `data` type -- to be able to get these
    somehow.  <br>
    <br>
    We did several extensive explorations of various options, but they
    all fail at the same root: that unless you declare your class in a
    special way where where these things all use all the state
    components (which is how records do it), the user will surely have
    some opinion about which field values feed into the derivation (and
    possibly how -- e.g., are arrays handled by identity or by
    content?)  And not all deriviations will want to use the same set of
    field values.  (And OMG what about mutability.  And for accessors,
    what about name selection?  Etc etc.)  When you sketch it out, you
    end up with something that is basically a syntax generator with
    about the same (enormous) programming model surface as typical
    "bean" generators -- which is to say, a mess, and a mess for which
    no solution will be complete enough.  (Our mantra for records was
    that zero was the only acceptable number of "knobs", because once
    there is one knob, there are arbitrarily many.)  <br>
    <br>
    So while it may sound like a "logical next step", the complexity
    goes up by orders of magnitude, and you lose the best thing about
    records at the same time -- that record-ness is a semantic, not
    syntactic, construct.  So I am skeptical about that step.<br>
    <br>
    <blockquote type="cite">
      <pre>The second feature: pattern matching on LHS of assignment.

Suppose we have this record type:

record Color(byte red, byte green, byte blue) {}

and a static factory method “someFactory” which returns a Color.

Are there any plans to allow us to pattern match at the point of assignment like so:

Color(byte red, byte green, byte blue) color = someFactory();

This would be a great addition to pattern matching.
</pre>
    </blockquote>
    <br>
    Imperative pattern matching is reasonable and well understood, but
    (a) it is not yet the highest-leverage remaining pattern matching
    feature (and so remains lower on the queue) and (b) still has
    several rough edges to work out.  There are actually two versions of
    imperative pattern matching that people might want: one which is
    "total" (it is a compile error to try to deconstruct a target with a
    pattern that is not exhaustive, and one which is "partial" (one that
    just throws on non-match, as if you had "cast" the target to the
    pattern.)   So this is on the back burner for now.<br>
    <br>
    <br>
  </div>

</blockquote></div>