As it appears that Jestr duplicates some lang functionality, I am hoping that a non-project-whole approach can be taken. Perhaps the Jestr author (David) would be interested in improving [lang] by implementing new features in [lang].
So this would not involve any lock-stock-and-barrel Jestr project import but rather writing new lang code inspired by Jestr assuming David is interested. Gary > -----Original Message----- > From: Martin Cooper [mailto:[EMAIL PROTECTED] > Sent: Monday, March 08, 2004 19:29 > To: Jakarta Commons Developers List > Cc: [EMAIL PROTECTED] > Subject: RE: Proposal for the Commons Sandbox > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
