<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">There was some investigation into
exposing invokedynamic (see the video "Below the Fold" from JVMLS
a few years ago.) I doubt that this entirely solves the issue but
it is something we'd like to do someday.</font><br>
<br>
<br>
<div class="moz-cite-prefix">On 12/5/2024 11:32 AM, Glavo wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJL5A3=LQu53Wv=sSwEA=HmTa3_uH1dXY-CgBDmH6zQyg=L8iQ@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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">
<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>
</blockquote>
<br>
</body>
</html>