Data Oriented Programming, Beyond Records

[Archie Cobbs]

I feel like Remi has a good point somewhere in here, though I'm not sure I
can articulate it any better than he does....

On Wed, Jan 21, 2026 at 12:02 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> So there are two stabled, principled alternatives:
>
>  - Just don't ever try to derive equals and hashCode
>  - Derive equals and hashCode similarly as for records
>
> And of course, the first means that records cannot be considered special
> cases of carriers.  So the latter seems a forced move.
>

Hmm... why not? Can we not say: "A record is a special case of a carrier
that ... and also auto-generates equals() and hashCode()" ?

[ There is some implied heresy here, which is that maybe it was wrong for
records to auto-generate equals/hashCode in the first place. I found it a
bit surprising the first time I tried to put some public record
GraphNode objects
into a Set and inadvertently created a bunch of infinite loops which I had
to fix by overriding equals() with == and hashCode() with
System.identityHashCode(). But obviously that horse is out of the barn... ]

In other words, I like Remi's conceptual idea of carrier classes being
"(possibly abstract) things with virtual components". Really that's almost
like saying "modernized java beans". Then a record could still be a
specialized, locked down, concrete form of a carrier class.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20260121/2dceee15/attachment-0001.htm>