Yes, I think Jestr could be incorporated cleanly into the ToStringBuilder hierarchy, either as a subclass of ToStringBuilder, or as a subclass of ReflectionToStringBuilder.
I would be happy to incorporate it into org.apache.commons.lang.builder, but there's just something about this categorization that bugs me a little: Isn't the term "builder" a bit misleading here? After all, Jestr doesn't really care if I am building a toString() method or not, and if I am stringifying some legacy or third party class, then what exactly am I "building"? ---------- Original Message ---------------------------------- From: "Gary Gregory" <[EMAIL PROTECTED]> Reply-To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Date: Mon, 8 Mar 2004 13:43:51 -0500 >Hello, > >> However I think Jestr is a >> little different from the ToStringBuilder stuff because it isn't >> necessarily concerned with helping you implement toString() methods; >> instead, it's more concerned with helping you log *arbitrary* objects, >> even if you don't have access to their source code to change their >> toString() methods. > >Note that the o.a.c.l.builder package also provides the ability to >operate on an arbitrary object. Please see: > >(1) The class ReflectionToStringBuilder: > >http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/build >er/ReflectionToStringBuilder.html > >(2) The ToStringBuilder methods which forward to >ReflectionToStringBuilder: > >http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/build >er/ToStringBuilder.html#reflectionToString(java.lang.Object) > >Gary > > >--------------------------------------------------------------------- >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]
