<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"Viktor Klang" <viktor.klang@oracle.com>, "amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Sent: </b>Wednesday, January 21, 2026 7:49:26 PM<br><b>Subject: </b>Re: Data Oriented Programming, Beyond Records<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><blockquote cite="mid:1481652515.22449673.1769020576885.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div>
<blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br>
So there are two stabled, principled alternatives:<br>
<br>
- Just don't ever try to derive equals and hashCode <br>
- Derive equals and hashCode similarly as for records<br>
<br>
And of course, the first means that records cannot be
considered special cases of carriers. So the latter seems a
forced move. </blockquote>
<div><br>
</div>
<div>I still think there is value to consider that a carrier
class is an abstract specification that just say that it can
be constructed/deconstructed but equals/hashCode are user
defined.</div>
<div><br>
</div>
<div>When you use only pattern matching, you do not really
need equals/hashCode to be defined, you recursively
pattern-match until you have primitive values.</div>
<br>
</div>
</div>
</blockquote>
<br>
I agree that it is a valid question to ask: "does declaring a state
description for a carrier class influence the Object behaviors."
And I do understand why you are attracted to this; once we leave the
strict representation constraints of records, it feels somewhat less
anchored, primarily because "mutability." <br>
<br>
But also, you pay a big complexity tax when the new concept is
almost like but can't quite fully meet up with the old concept; it
again means that refactoring from record <--> carrier comes
with a significant sharp edge, and this is a big warning signal. So
we would need a much stronger reason than "hmm, kind of like it
better this way" to choose this divergent path. So far I'm not
seeing it?</blockquote><div><br></div><div>There is a big sharp edge between a record and a class which is due to mutability, this is true inside the class but also outside, the user code when something is mutable or not is quite different .So refactoring from a mutable class to to an unmodifiable record is a not battle we should be interested in.</div><div><br data-mce-bogus="1"></div><div>And if we force unmodifiability on a class, we loose half of the use cases. </div><div><br data-mce-bogus="1"></div><div>So what are exactly the refactoring you are envisioning that have a significant sharp edges ?</div><div><br></div><div>regards,</div><div>Rémi</div><div><br data-mce-bogus="1"></div></div></div></body></html>