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: Tuesday, January 20, 2026 2:23:13 AM
> 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. 

>> I have used HashSet as an example to say that I would prefer
>> equals/hashCode/toString not to be generated so my students can launch the
>> debugger to understand why it does not work as intended.

> "Generation" is not the right level for this discussion, though. This feature is
> not a Lombok macro generator; it is a semantic feature. Can you restate this in
> terms of what you think such as class should _mean_?
As far as i understand, the carrier class syntax 
class Point(int x, int y) { ... } 
means that 
- if it's not a concrete class, the implementation should provide an implementation for the canonical constructor and accessors, 
- if it's an interface or an abstract class, the accessors are generated as abstract methods. 

Then declaring a field as "component" generates the canonical constructor, the corresponding accessor and toString/equals/hashCode. 

I see those two features as separated, and i am not convince that the latter is worth it. 
For me, all the juice come from the carrier class semantics. 

As i said earlier, I think that providing an implementation for toString/equals/hashCode is not a good idea. 
Given that the class can be mutable, generating equals and hashCode hide important details that are necessary for debugging and I also think it does not makes no sense for an enum (you did not answer that question ?). 

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