Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposal for the Commons Sandbox
Date: Mon, 8 Mar 2004 23:46:12 -0500
Message-ID: <D1639D06CFBD014F87F3978DA7038B933F94A0@ns1017.SSSI.seagull.nl>
Thread-Topic: Proposal for the Commons Sandbox
Thread-Index: AcQFhrZM3QnDKmL+RzuHIRi9L8fo3wABrPcA
From: "Gary Gregory" <ggregory@seagullsw.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Cc: <dgilliland62@users.sourceforge.net>

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].=20

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
>=20
> On Mon, 8 Mar 2004, Gary Gregory wrote:
>=20
> > 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.
>=20
> 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.
>=20
> --
> Martin Cooper
>=20
>=20
> >
> > 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
> >
> >
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20


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