Re: “Deriving” functionality for classes and pattern matching on LHS of assignment?

[Glavo]

Is it possible to solve this issue by making Java support invokeDynamic
syntactically?
Users can provide their own helper classes similar to
java.lang.runtime.ObjectMethods to synthesize methods.

Glavo

On Thu, Dec 5, 2024 at 11:16 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
>
> On 12/5/2024 4:34 AM, vab2048 wrote:
>
> 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.
>
>
> 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.
>
> 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.)
>
> 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.
>
> 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.
>
>
> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241206/354eb490/attachment.htm>