Of course, Struts could (almost) get the best of both worlds by wrapping ToStringBuilder inside a Struts class and use that class instead. The small overhead of the extra call would only kick in when logging is enabled. Whenever it's decided that c-l.TSB dependency should be dropped, it's easy enough to put implementation code in (in this case). Either way, you'd still get object reuse, ease of use, and consistent implementation across the codebase. It's also easy enough that if any of the committers didn't wanna do it, someone else will. Plus, if like David said, lists need to be handled differently, it can be programmed in and reused by other classes, again for consistency.
--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > Quoting David Graham <[EMAIL PROTECTED]>: > > > I think we inherit the dependency on commons lang from some other > > component. Our use of lang's features is very limited and my preference > > is to keep it that way. Regardless, toString() is easy to implement > > without ToStringBuilder. > > > > Last time I looked, ToStringBuilder was the only dependency we have on > commons-lang. I'd much rather do a little more work in our toString() methods > and dump the dependency if that's actually the case, unless there's some > compelling need for any of the other c-l methods. > > > David > > Craig > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
