lianetm commented on PR #15750:
URL: https://github.com/apache/kafka/pull/15750#issuecomment-2066727111
Thanks for the info @kirktrue , I see you mentioned it was a "suggested
pattern", and I won't hold a strong position here but still sharing how I see
it (struggling to find a value in it that compensates the drawbacks)
Drawbacks:
- overcomplicated flow to understand where a class `toString` comes from
(back-and-forth between a child class and its parent): child has no `toString`,
jump to parent that has it but uses a `toStringBase`, defined in the parent but
redefined in the child, so jump back to child where `toStringBase` is
redefined. I find more intuitive/simpler to just have child classes with
`toString` that uses a `toStringBase` defined in parent (like its name clearly
indicates).
Value it brings:
> It allows the parent to keep its state private, but still "expose" it via
toString()
We get exactly the same in both alternatives. Parent keeps state private,
exposed via toStringBase/toString
> It helps to ensure the correct class name appears in the output
This was actually not happening when I reviewed this PR the first time, and
it was indeed confusing. Still with the fix to get the child class name in the
parent, I wonder if it's worth the ping-pong? A child class using a wrong class
name in the `toString` seems like an unlikely silly bug, easy to catch/fix
during the initial development phase.
> It keeps the output uniform and reminds the developer to keep the parent
state
A little bit more uniform, yes, but only as long as the developer does it
right when overriding the `toStringBase` right? So we're just kind of shifting
the responsibility from overriding the toString properly, to overriding the
toStringBase properly (at the expense of the ping-pong). And we're not truly
reminding the developer unless we have an abstract method I would say, which is
not the case.
Just sharing my thoughts, I may be bothered by the ping-pong flow more than
others in this case ;)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
