On Mon, Sep 29, 2025 at 2:53 PM Rob Spoor <[email protected]> wrote: > > 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
Ah! Got it. Fixed in git master and snapshot builds. William, please verify your use case. TY all, Gary > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
