Data Oriented Programming, Beyond Records

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Viktor Klang" <viktor.klang at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, January 21, 2026 7:49:26 PM
> Subject: Re: Data Oriented Programming, Beyond Records

>>> 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.
>> 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.

>> 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.

> 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."

> 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?
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. 

And if we force unmodifiability on a class, we loose half of the use cases. 

So what are exactly the refactoring you are envisioning that have a significant sharp edges ? 

regards, 
Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20260121/2c436ca2/attachment.htm>