Data Oriented Programming, Beyond Records

[Brian Goetz]

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

Just because carrier class state _can_ be mutable, doesn't mean it 
_must_ be.  So you're skipping over the interesting case, which is:

     record R(int x, ...) { }

and

     final class R(int x, ...) { private final component int x; ... }  
// not equivalent to above!

In your model, the class version of R is painful to write, because you 
have to write equals, hashCode, and toString that delegate to each of 
the components.  But that's not even the main point; it is that while 
there is no theoretical distinction between a record and a final class 
all of whose components are backed by final component fields, there is a 
big and hard-to-explain discontinuity when you start from either of 
those and try to refactor to the other.

But you are still not justifying your preference; WHY is identity-based 
equality the *obviously right* choice for carriers? Be semantic please!  
Tell me what you think a carrier *means*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20260121/95b0fa57/attachment-0001.htm>