> From: "Brian Goetz" <[email protected]>
> To: "Remi Forax" <[email protected]>
> Cc: "Viktor Klang" <[email protected]>, "amber-spec-experts"
> <[email protected]>
> 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
