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

[Brian Goetz]

As a correction: annotation processors cannot do this _in place_.  This 
is by design: it was an anti-goal of annotation processors to turn them 
into macro generators.

An annotation processor can (with some extra work) generate _other_ 
compilation units, which could even be subclasses or superclasses of the 
annotated class, but cannot generate members _into_ any existing class.  
(Again, by design: the prime directive of annotations is that it _cannot 
affect the language semantics of the class being annotated_; annotations 
are metadata.)

(I suspect people will be tempted to argue with the above, because many 
many people wish the world were different.  But, this argument has been 
had to death, and amber-dev is certainly not the place to re-hash this.)

But you are correct that building one specific ad-hoc, syntax-focused 
annotation processor into the language would be a major mistake, because 
it would be mixing abstractions.


On 12/5/2024 10:01 AM, Ethan McCue wrote:
> (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/20241205/1dc0bf10/attachment-0001.htm>