Data Oriented Programming, Beyond Records

[Brian Goetz]

>
>     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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20260121/3fee3663/attachment.htm>