<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font face="monospace" size="4">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. <br>
<br>
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.) <br>
<br>
(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.)<br>
<br>
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. <br>
</font><br>
<br>
<div class="moz-cite-prefix">On 12/5/2024 10:01 AM, Ethan McCue
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CA+NR86gNoT8EsAx5Sv8GmZEOLHObvetLx3yhUUkAcsMNjVJNdg@mail.gmail.com">
<div dir="ltr">(nonauthoritative opinion)<br>
<br>
For the first point: While it has its downsides, that capability
already exists in the form of code generating annotation
processors.<br>
<br>
I.E. it is possible to have<br>
<br>
<font face="monospace">@Ordered<br>
public record Hill(int heightAboveSeaLevel) <br>
implements HillComparable {<br>
}</font>
<div><font face="monospace"><br>
</font></div>
<div><font face="arial, sans-serif">Generate<br>
<br>
</font><font face="monospace">interface HillComparable extends
Comparable<Hill> {</font><br>
<font face="monospace"> @Override</font><br>
<font face="monospace"> default int compareTo(@NotNull Hill
o) {</font><br>
<font face="monospace"> return Comparator</font><br>
<font face="monospace">
.comparingInt(Hill::heightAboveSeaLevel)</font><br>
<font face="monospace"> .compare(this, o);</font><br>
<font face="monospace"> }</font><br>
<font face="monospace">}</font><br>
<br>
<font face="arial, sans-serif">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.</font></div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Thu, Dec 5, 2024 at 9:02 PM
Gavin Bierman <<a href="mailto:gavin.bierman@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">gavin.bierman@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>
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].
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks for your interest!</div>
<div>Gavin</div>
<div><br>
</div>
<div>[1]: <span style="white-space:pre-wrap"> </span><a href="https://openjdk.org/projects/amber/design-notes/patterns/pattern-match-semantics" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://openjdk.org/projects/amber/design-notes/patterns/pattern-match-semantics</a></div>
<div><span style="white-space:pre-wrap"></span><a href="https://openjdk.org/projects/amber/" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://openjdk.org/projects/amber/</a></div>
<div><br id="m_-512231407546079143lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 5 Dec 2024, at 09:34, vab2048 <<a href="mailto:vab2048@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">vab2048@gmail.com</a>>
wrote:</div>
<br>
<div>
<div>Hi Amber team,<br>
<br>
I was wondering about the future of two different
features and thought I would just ask the mailing
list.<br>
<br>
The first feature: deriving instances. <br>
<br>
Haskell allows type declarations to derive
instances for certain type classes (Eq, Ord, Enum,
Bounded, Show, and Read).<br>
<br>
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. <br>
<br>
The second feature: pattern matching on LHS of
assignment.<br>
<br>
Suppose we have this record type:<br>
<br>
record Color(byte red, byte green, byte blue) {}<br>
<br>
and a static factory method “someFactory” which
returns a Color.<br>
<br>
Are there any plans to allow us to pattern match
at the point of assignment like so:<br>
<br>
Color(byte red, byte green, byte blue) color =
someFactory();<br>
<br>
This would be a great addition to pattern
matching.<br>
<br>
<br>
Regards,<br>
<br>
Vikram<br>
<br>
<br>
<br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>