Data Oriented Programming, Beyond Records

forax at univ-mlv.fr forax at univ-mlv.fr
Tue Jan 20 18:35:20 UTC 2026


> 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: Tuesday, January 20, 2026 4:28:14 PM
> Subject: Re: Data Oriented Programming, Beyond Records

>>>> The modifier "component" is too close to the "property" modifier I wanted to
>>>> include years ago, it's just to sugary for its own good.

>>> You know the rule; mention syntax and you forfeit the right to more substantial
>>> comments....
>> I'm talking about the semantics, especially the fact that equals/hashCode and
>> toString() are derived from.

> Except that equals/hashCode have nothing to do with the "component" modifier _at
> all_. They are derived from the _state description_, in terms of the
> _accessors_, whose existence is implied directly by the _state description_.
I do not think you can do that, because it means that a record is not a carrier class. 

Do you agree that equals() and hashCode() of a record are not derived from the accessors ? 

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


More information about the amber-spec-experts mailing list