commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Gilliland" <dgillilan...@users.sourceforge.net>
Subject RE: Proposal for the Commons Sandbox
Date Tue, 09 Mar 2004 13:50:59 GMT
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" <ggregory@seagullsw.com>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
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:martinc@apache.org]
>> Sent: Monday, March 08, 2004 19:29
>> To: Jakarta Commons Developers List
>> Cc: dgilliland62@users.sourceforge.net
>> 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:dgilliland62@users.sourceforge.net]
>> > > 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" <ggregory@seagullsw.com>
>> > > 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:dgilliland62@users.sourceforge.net]
>> > > >> 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" <ggregory@seagullsw.com>
>> > > >> Reply-To: "Jakarta Commons Developers List" <commons-
>> > > >> dev@jakarta.apache.org>
>> > > >> 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:
>commons-dev-unsubscribe@jakarta.apache.org
>> > > >> >For additional commands, e-mail:
>> > commons-dev-help@jakarta.apache.org
>> > > >> >
>> > > >> >
>> > > >>
>> > > >>
>> >
>---------------------------------------------------------------------
>> > > >> To unsubscribe, e-mail:
>commons-dev-unsubscribe@jakarta.apache.org
>> > > >> For additional commands, e-mail:
>> > commons-dev-help@jakarta.apache.org
>> > > >>
>> > > >
>> > > >
>> > > >
>> >
>> >
>> >
>> >
>---------------------------------------------------------------------
>> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> >
>> >
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> 
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message