On Mon, 8 Mar 2004, Gary Gregory wrote: > 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.
If Jestr is going to come to Apache, I believe it would need to do so via the incubator. We can't accept external projects from non-Apache folks straight into Commons, sandbox or otherwise. -- Martin Cooper > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
