Question about records and overriding their "magic methods"

[David Alayachew]

Hello Brian,

Thank you for your response!

> We explored this topic
> ...
> but concluded that this failed the power-to-weight-ratio
> test

Makes a lot of sense. This is only ever going to apply to "magic methods".

> because usually you do not want to _refine_ an equals/toString/hashCode
calculation, but instead broaden it

Makes a lot of sense. In my ~1.5 years of using records, this is the second
time I have ever had the desire to refine the outcome of a "magic method".

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

I see what you mean. Today, I wanted to include a derived value to the
toString. What if I also wanted to include these derived values "inside" of
the square brackets? Makes a lot of sense.

> Leave "future you" some comments for what you were
> thinking today.

Makes sense. I think the value of overriding toString is not very much in
the long run, so rather than overriding, I'll just take the extra lap and
insert the .map() call to my streams instead of being lazy.

Or I could do the "ugly" solution that Rémi came up with lol.

Thank you for your time and help!
David Alayachew


On Thu, Sep 21, 2023 at 1:18 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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/ccd8db5c/attachment.htm>