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

Ethan McCue ethan at mccue.dev
Thu Dec 5 15:01:12 UTC 2024


(nonauthoritative opinion)

For the first point: While it has its downsides, that capability already
exists in the form of code generating annotation processors.

I.E. it is possible to have

@Ordered
public record Hill(int heightAboveSeaLevel)
        implements HillComparable {
}

Generate

interface HillComparable extends Comparable<Hill> {
    @Override
    default int compareTo(@NotNull Hill o) {
        return Comparator
                .comparingInt(Hill::heightAboveSeaLevel)
                .compare(this, o);
    }
}

The problem is that all such code generators - if they were built into the
language - would have restrictions on the contexts in which they are
applicable. Fundamentally records can only have toString, equals, and
hashCode derived for them because by virtue of being a record the language
knows that it is just a thin data carrier. It is much  more dubious to do
something similar for regular classes.

On Thu, Dec 5, 2024 at 9:02 PM Gavin Bierman <gavin.bierman at oracle.com>
wrote:

> I can speak to the second point: Yes, this is very much on our radar.
> There has been discussion of this on this list I believe (or maybe on the
> spec-experts list), and it is mentioned in early design documents that you
> can read on the Amber project page [1].
>
> There are other places that we would like to consider to support patterns,
> e.g. in the head of lambda expressions and in enhanced for statements. We
> may well do these all in one go.
>
> Thanks for your interest!
> Gavin
>
> [1]:
> https://openjdk.org/projects/amber/design-notes/patterns/pattern-match-semantics
> https://openjdk.org/projects/amber/
>
>
> On 5 Dec 2024, at 09:34, vab2048 <vab2048 at gmail.com> 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 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.
>
>
> Regards,
>
> Vikram
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241206/e14813a7/attachment-0001.htm>


More information about the amber-dev mailing list