Yes, I tend to agree that Lang would be the cleanest place to implement this functionality, since as you say there is clearly some overlap with ReflectionToStringBuilder. In a sense, Jestr is ReflectionToStringBuilder on a massive dose of steroids ;-)
However, this approach would introduce some dependencies on non-Lang components (IO, Collections, etc) into Lang (the Functor dependency is quite trivial and easily removed, but the others are used heavily). I don't know if this is an issue or not. Also, there is the dependency on the properties file for configuration, which is an unfortunate hack that I hope to replace with Commons Configuration. Thus there would be a dependency from Lang to Configuration. Again, I don't know if that's an issue or not. Is there any precedent for a Configuration dependency of this sort? --David ---------- Original Message ---------------------------------- From: "Gary Gregory" <[EMAIL PROTECTED]> Reply-To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Date: Mon, 8 Mar 2004 23:46:12 -0500 >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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
