Question about records and overriding their "magic methods"

[Brian Goetz]

We explored this topic somewhat when designing the feature.

When you override a method x, you can still delegate (via super.x()) to 
the thing you override.  We considered doing the same here (delegating 
to default.x()), but concluded that this failed the 
power-to-weight-ratio test, because usually you do not want to _refine_ 
an equals/toString/hashCode calculation, but instead broaden it (such as 
comparing arrays by contents rather than by ==.)

If you pull on this "string" a bit, the API that you would want here is 
complex and enormous, and has as many tuning knobs as a Lombok.  So 
refactoring records that customize Object methods becomes a 
higher-responsibility activity.  Leave "future you" some comments for 
what you were thinking today.



On 9/21/2023 1:00 PM, David Alayachew wrote:
> Hello Amber Dev Team,
>
> Let's say I have a record like the following.
>
> record ComplexRecord(int blah /* and many more components */) {}
>
> Next, let's say that I want to override my toString, to include some 
> derived information.
>
> Obviously, putting the derived info into the toString is easy, but how 
> do I go about INCLUDING it with my original implementation of toString 
> that was magically created for me by Java?
>
> If I try to fully recreate my toString, I run the risk of it becoming 
> out-of-date upon refactor. Best I can come up with is nesting another 
> record with the toString overloaded. Also not ideal.
>
> Thank you for your time!
> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230921/5322bd53/attachment.htm>