commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject RE: Proposal for the Commons Sandbox
Date Tue, 09 Mar 2004 03:28:54 GMT
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


Mime
View raw message