Hello, The set up you describe, if at all possible, seems too twisty to me.
Here is what you could consider, perhaps one of: (0) Do nothing: you and your users are happy to use Jestr and/or commons-lang. I assume this is a no-go since you posted your message to commons-dev ;-) (1) Simple: Merge Jestr into builder. No functor dependency. (2) Recast Jestr as a sandbox project extending and depending on commons-lang. This is kind of like (1) but with the added overhead of it being an extra project. No matter what, I would start by outlining what additional features this would give commons-lang. I took a brief look at the Jestr page, and I am a bit busy right now (aren't we all!). For example, I noticed something to do with configuring the component from a file, which the builder package does not do for ToStringBuilder. So that's an interesting delta. Instead of making everyone figure out for themselves what the deltas are between [lang] and Jestr, why not provide a list? This way everyone can say, whether or not such and such a feature makes sense to add. Then you can write bugzilla tickets for each new feature and go at it. Side note: Personally, I am no fan of functors. There is no such thing as Smalltalk block in Java, very sad, and trying to emulate such things with interfaces is, IMHO, just too heavy handed and looks very cumbersome syntactically. Cheers, Gary > -----Original Message----- > From: David Gilliland [mailto:[EMAIL PROTECTED] > Sent: Monday, March 08, 2004 14:56 > To: Gary Gregory > Subject: RE: Proposal for the Commons Sandbox > > Hey Gary, > > Question for you: Supposing that Jestr were to be incorporated into > commons.lang.builder, would it be possible to keep the Jestr portions in > the sandbox while the rest of commons.lang.* remained in the Commons > proper? Jestr depends on Commons Functor (which is sandboxed) and is thus > ineligible for Commons proper at this point. > > Thanks, > David > > ---------- Original Message ---------------------------------- > From: "Gary Gregory" <[EMAIL PROTECTED]> > Date: Mon, 8 Mar 2004 15:23:25 -0500 > > >In this case you are building a java.lang.String. Simple answer eh? ;-) > > > >The [Reflection]ToStringBuilder is used to create a String based on > >other Objects. The most common usage is to implement an Object's > >toString() method with a [Reflection]ToStringBuilder. You can also use > >the string builder classes to build a String for any object of course. > > > >For example, it can be useful for debugging purposes to use a > >ReflectionToStringBuilder toString to dump the contents of an arbitrary > >object. > > > >For the package as a whole, the term builder applies to the notion of > >building different kinds of algorithms for us with toString(), equals(), > >compareTo(), and hashCode(). Builder might not be a great name but it is > >hard to think of a name that says: "Assits in overriding methods that > >are in Object: toString(), hashCode(), equals(), and also compareTo()." > > > >Gary > > > >> -----Original Message----- > >> From: David Gilliland [mailto:[EMAIL PROTECTED] > >> Sent: Monday, March 08, 2004 11:13 > >> To: Jakarta Commons Developers List > >> Subject: RE: Proposal for the Commons Sandbox > >> > >> 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" <commons- > >> [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/bui l > >d > >> >er/ReflectionToStringBuilder.html > >> > > >> >(2) The ToStringBuilder methods which forward to > >> >ReflectionToStringBuilder: > >> > > >> > >>http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui l > >d > >> >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] > >> > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
