I'm thinking that William meant that the ToStringStyle methods that are
called by ToStringBuilder are using fields, not methods. For instance,
direct use of "useClassName" at
https://github.com/apache/commons-lang/blob/30c465267d2e9649cbb194b666b58ad492c624ea/src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java#L1155.
This is unlike "useIdentityHashCode" that is used through its getter at
https://github.com/apache/commons-lang/blob/30c465267d2e9649cbb194b666b58ad492c624ea/src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java#L1584
On 29/09/2025 19:08, Gary Gregory wrote:
On Mon, Sep 29, 2025 at 12:50 PM Rob Spoor <[email protected]> wrote:
I've just checked for version 3.18.0, but every field in ToStringStyle
has a protected getter and setter. Is it not possible to call the
setters instead? The nested sub classes of ToStringStyle call these
setters in their constructors.
I read the initial request as wanting to (1) override some
ToStringStyle getter method(s), and (2) have these getters used
internally for field access. This looks to me like it is already the
case in the code. All fields in ToStringStyle are only accessed from
ToStringStyle, nothing from ToStringBuilder.
So I am missing something here. But what?
Gary
On 2025/09/29 11:43:12 William Degrange wrote:
Hi all,
I would like to propose a small improvement in ToStringStyle.
Currently, some boolean fields in ToStringStyle are accessed directly in
ToStringBuilder instead of through their getters. This prevents subclasses from
overriding the behavior.
My proposal is to switch the code to use the getters instead of direct field
access. This would allow subclasses to provide dynamic behavior, for example,
returning values based on a logger’s debug level, without needing to create a
new ToStringStyle instance for every toString() call.
Before opening a PR, I wanted to discuss this with the community to confirm
that this approach is acceptable.
Any thoughts or concerns?
Note : this is already the case for the 'useIdentityHashCode' field.
Thanks,
William
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
