You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Steven Caswell <st...@caswell.name> on 2003/06/04 02:32:26 UTC
[beanutils] extending BasicDynaBean with toString, equals, and hashCode
I've written an extended dynabean class that extends (actually, wraps)
BasicDynaBean to add toString and equals. The toString method uses
commons.lang.ToStringBuilder to build the toString, and
commons.lang.EqualsBuilder to perform the equals comparison. I know it needs
hashCode, I just haven't taken the time to add it yet.
Is there any interest in having this class donated to commons-beanutils?
Steven Caswell
steven@caswell.name
"In our own native land, in defense of the freedom that is our birthright,
and which we ever enjoyed till the late violation of it -- for the
protection of our property, acquired solely by the honest industry of our
fore-fathers and ourselves, against violence actually offered, we have taken
up arms. We shall lay them down when hostilities shall cease on the part of
the aggressors, and all danger of their being renewed shall be removed, and
not before." - Thomas Jefferson
Re: [beanutils] extending BasicDynaBean with toString, equals, and hashCode
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tuesday, June 17, 2003, at 06:33 AM, Craig R. McClanahan wrote:
> On Sat, 14 Jun 2003, robert burrell donkin wrote:
>> maybe it's time to think about adding an optional package
>> (org.apache.commons.beantuils.optional?) and a build for a
>> beanutils-optional.jar inspired by the way that ant manages non-core
>> dependencies. this would allow new implementations with dependencies to
>> be
>> added to the component without adding to the core-dependencies of
>> beanutils.
>>
>
> I would be +1 on doing this (at least until we were ready for a BeanUtils
> 2.x version where I'd be OK with adding dependencies) in ordser to
> accomodate an extended version of BasicDynaBean. I continue to be -1 on
> adding an external dependency in BeanUtils 1.x, for pretty much ANY reason
> (two years of use by lots of different folks makes it pretty clear that
> the "as is" package is pretty darn useful :-)
>
> Quite frankly, the value add -- to BeanUtils users, not from the Lang
> perspective -- just isn't all that high. It exists, but not enough to
> disrupt the lives of the very large number of projects that currently
> depend on BeanUtils (see the Gump dependency chart for a small subset of
> the people that would be impacted by such a change).
i think that an optional jar will open up a lot of interesting avenues -
not just for this, but for implementations of the bean query language
strategies suggested by rune. even for 2.0, i think that we'd be serving
everyone better if we kept the core dependencies to a minimum but factor
beanutils in a more flexible way so that people could - if they wished -
plug in more sophisticated strategies with more dependencies from the
optional jar.
it's just a pity that i've got so little time at the moment and don't have
the energy to push this forward...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] extending BasicDynaBean with toString, equals, and
hashCode
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 14 Jun 2003, robert burrell donkin wrote:
> Date: Sat, 14 Jun 2003 10:43:41 +0100
> From: robert burrell donkin <ro...@blueyonder.co.uk>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [beanutils] extending BasicDynaBean with toString, equals,
> and hashCode
>
> maybe it's time to think about adding an optional package
> (org.apache.commons.beantuils.optional?) and a build for a
> beanutils-optional.jar inspired by the way that ant manages non-core
> dependencies. this would allow new implementations with dependencies to be
> added to the component without adding to the core-dependencies of
> beanutils.
>
I would be +1 on doing this (at least until we were ready for a BeanUtils
2.x version where I'd be OK with adding dependencies) in ordser to
accomodate an extended version of BasicDynaBean. I continue to be -1 on
adding an external dependency in BeanUtils 1.x, for pretty much ANY reason
(two years of use by lots of different folks makes it pretty clear that
the "as is" package is pretty darn useful :-)
Quite frankly, the value add -- to BeanUtils users, not from the Lang
perspective -- just isn't all that high. It exists, but not enough to
disrupt the lives of the very large number of projects that currently
depend on BeanUtils (see the Gump dependency chart for a small subset of
the people that would be impacted by such a change).
> - robert
Craig
>
> On Thursday, June 12, 2003, at 11:33 PM, Steven Caswell wrote:
>
> > My use of the lang.builder is in fact the non-reflection part. I simply
> > look
> > at the dynabean's dynaclass, ask it for the array of dyna properties, then
> > step through the array and call gets on the dynabean for each property,
> > passing the result to the appropriate builder.
> >
> > I understand any hesitancy to add an external dependency without good
> > reason. Of course IMHO, adding a dependency to lang would be appropriate
> > here because of the benefits of having this basic functionality
> > encapsulated
> > in the lang.builder package. While the implementation of toString and
> > equals
> > could be redone without lang.builder, it would be more work (which would
> > be
> > more error-proned) to do a hashCode implementation in a similar manner. I
> > think it would be a shame to waste the great effort of the lang folks who
> > put together the lang.builder package.
> >
> > I use many of the pieces on a daily basis, esp. the lang.builder stuff.
> > IMHO
> > it is pretty solid, so I think the risk to beanutils of a dependency on
> > lang
> > would be minimal.
> >
> >
> > Steven Caswell
> > steven@caswell.name
> > a.k.a Mungo Knotwise of Michel Delving
> > "One ring to rule them all, one ring to find them..."
> >
> >
> >> -----Original Message-----
> >> From: Christoph.Reck@dlr.de [mailto:Christoph.Reck@dlr.de]
> >> Sent: Thursday, June 05, 2003 3:08 AM
> >> To: Jakarta Commons Developers List
> >> Subject: Re: [beanutils] extending BasicDynaBean with
> >> toString, equals, and hashCode
> >>
> >>
> >> The concept of ToStringBuilder and EqualsBuilder ist good,
> >> but not completely suited for BeanUtils - the reflection
> >> pattern used does not consider the accessor methods for beans.
> >>
> >> If your extended dynabean does the explicit use of the
> >> lang.builder code w/o the reflection parts, it should suite
> >> the bean use pattern. A dependency of beanutils on lang will
> >> need acceptance voting from the committers (to me seems to be
> >> OK, since lang is even lower level than beans).
> >>
> >> It might be sensible to factor out parts from the
> >> lang.builder implementations to be then subclassed once for
> >> beans and once for full filed reflection usage?
> >>
> >> Just my 2c!
> >>
> >> Craig R. McClanahan wrote:
> >>>
> >>> On Tue, 3 Jun 2003, Steven Caswell wrote:
> >>>
> >>>
> >>>> Date: Tue, 3 Jun 2003 20:32:26 -0400
> >>>> From: Steven Caswell <st...@caswell.name>
> >>>> Reply-To: Jakarta Commons Developers List
> >> <co...@jakarta.apache.org>,
> >>>> steven@caswell.name
> >>>> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> >>>> Subject: [beanutils] extending BasicDynaBean with toString, equals,
> >>>> and hashCode
> >>>>
> >>>> I've written an extended dynabean class that extends
> >> (actually, wraps)
> >>>> BasicDynaBean to add toString and equals. The toString method uses
> >>>> commons.lang.ToStringBuilder to build the toString, and
> >>>> commons.lang.EqualsBuilder to perform the equals
> >> comparison. I know it
> >>>> needs hashCode, I just haven't taken the time to add it yet.
> >>>>
> >>>> Is there any interest in having this class donated to
> >>>> commons-beanutils?
> >>>>
> >>>
> >>>
> >>> Conceptually, I like the idea. My only concern is that it would
> >>> introduce a dependency on commons-lang that does not
> >> currently exist
> >>> in beanutils.
> >>>
> >>>
> >>>> Steven Caswell
> >>>
> >>>
> >>> Craig
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >> --
> >> :) Christoph Reck
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [beanutils] extending BasicDynaBean with toString, equals, and hashCode
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
maybe it's time to think about adding an optional package
(org.apache.commons.beantuils.optional?) and a build for a
beanutils-optional.jar inspired by the way that ant manages non-core
dependencies. this would allow new implementations with dependencies to be
added to the component without adding to the core-dependencies of
beanutils.
- robert
On Thursday, June 12, 2003, at 11:33 PM, Steven Caswell wrote:
> My use of the lang.builder is in fact the non-reflection part. I simply
> look
> at the dynabean's dynaclass, ask it for the array of dyna properties, then
> step through the array and call gets on the dynabean for each property,
> passing the result to the appropriate builder.
>
> I understand any hesitancy to add an external dependency without good
> reason. Of course IMHO, adding a dependency to lang would be appropriate
> here because of the benefits of having this basic functionality
> encapsulated
> in the lang.builder package. While the implementation of toString and
> equals
> could be redone without lang.builder, it would be more work (which would
> be
> more error-proned) to do a hashCode implementation in a similar manner. I
> think it would be a shame to waste the great effort of the lang folks who
> put together the lang.builder package.
>
> I use many of the pieces on a daily basis, esp. the lang.builder stuff.
> IMHO
> it is pretty solid, so I think the risk to beanutils of a dependency on
> lang
> would be minimal.
>
>
> Steven Caswell
> steven@caswell.name
> a.k.a Mungo Knotwise of Michel Delving
> "One ring to rule them all, one ring to find them..."
>
>
>> -----Original Message-----
>> From: Christoph.Reck@dlr.de [mailto:Christoph.Reck@dlr.de]
>> Sent: Thursday, June 05, 2003 3:08 AM
>> To: Jakarta Commons Developers List
>> Subject: Re: [beanutils] extending BasicDynaBean with
>> toString, equals, and hashCode
>>
>>
>> The concept of ToStringBuilder and EqualsBuilder ist good,
>> but not completely suited for BeanUtils - the reflection
>> pattern used does not consider the accessor methods for beans.
>>
>> If your extended dynabean does the explicit use of the
>> lang.builder code w/o the reflection parts, it should suite
>> the bean use pattern. A dependency of beanutils on lang will
>> need acceptance voting from the committers (to me seems to be
>> OK, since lang is even lower level than beans).
>>
>> It might be sensible to factor out parts from the
>> lang.builder implementations to be then subclassed once for
>> beans and once for full filed reflection usage?
>>
>> Just my 2c!
>>
>> Craig R. McClanahan wrote:
>>>
>>> On Tue, 3 Jun 2003, Steven Caswell wrote:
>>>
>>>
>>>> Date: Tue, 3 Jun 2003 20:32:26 -0400
>>>> From: Steven Caswell <st...@caswell.name>
>>>> Reply-To: Jakarta Commons Developers List
>> <co...@jakarta.apache.org>,
>>>> steven@caswell.name
>>>> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>>> Subject: [beanutils] extending BasicDynaBean with toString, equals,
>>>> and hashCode
>>>>
>>>> I've written an extended dynabean class that extends
>> (actually, wraps)
>>>> BasicDynaBean to add toString and equals. The toString method uses
>>>> commons.lang.ToStringBuilder to build the toString, and
>>>> commons.lang.EqualsBuilder to perform the equals
>> comparison. I know it
>>>> needs hashCode, I just haven't taken the time to add it yet.
>>>>
>>>> Is there any interest in having this class donated to
>>>> commons-beanutils?
>>>>
>>>
>>>
>>> Conceptually, I like the idea. My only concern is that it would
>>> introduce a dependency on commons-lang that does not
>> currently exist
>>> in beanutils.
>>>
>>>
>>>> Steven Caswell
>>>
>>>
>>> Craig
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>
>> --
>> :) Christoph Reck
>>
>>
>
>
>
> ---------------------------------------------------------------------
> 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
RE: [beanutils] extending BasicDynaBean with toString, equals, and hashCode
Posted by Steven Caswell <st...@caswell.name>.
My use of the lang.builder is in fact the non-reflection part. I simply look
at the dynabean's dynaclass, ask it for the array of dyna properties, then
step through the array and call gets on the dynabean for each property,
passing the result to the appropriate builder.
I understand any hesitancy to add an external dependency without good
reason. Of course IMHO, adding a dependency to lang would be appropriate
here because of the benefits of having this basic functionality encapsulated
in the lang.builder package. While the implementation of toString and equals
could be redone without lang.builder, it would be more work (which would be
more error-proned) to do a hashCode implementation in a similar manner. I
think it would be a shame to waste the great effort of the lang folks who
put together the lang.builder package.
I use many of the pieces on a daily basis, esp. the lang.builder stuff. IMHO
it is pretty solid, so I think the risk to beanutils of a dependency on lang
would be minimal.
Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
> -----Original Message-----
> From: Christoph.Reck@dlr.de [mailto:Christoph.Reck@dlr.de]
> Sent: Thursday, June 05, 2003 3:08 AM
> To: Jakarta Commons Developers List
> Subject: Re: [beanutils] extending BasicDynaBean with
> toString, equals, and hashCode
>
>
> The concept of ToStringBuilder and EqualsBuilder ist good,
> but not completely suited for BeanUtils - the reflection
> pattern used does not consider the accessor methods for beans.
>
> If your extended dynabean does the explicit use of the
> lang.builder code w/o the reflection parts, it should suite
> the bean use pattern. A dependency of beanutils on lang will
> need acceptance voting from the committers (to me seems to be
> OK, since lang is even lower level than beans).
>
> It might be sensible to factor out parts from the
> lang.builder implementations to be then subclassed once for
> beans and once for full filed reflection usage?
>
> Just my 2c!
>
> Craig R. McClanahan wrote:
> >
> > On Tue, 3 Jun 2003, Steven Caswell wrote:
> >
> >
> >>Date: Tue, 3 Jun 2003 20:32:26 -0400
> >>From: Steven Caswell <st...@caswell.name>
> >>Reply-To: Jakarta Commons Developers List
> <co...@jakarta.apache.org>,
> >> steven@caswell.name
> >>To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> >>Subject: [beanutils] extending BasicDynaBean with toString, equals,
> >> and hashCode
> >>
> >>I've written an extended dynabean class that extends
> (actually, wraps)
> >>BasicDynaBean to add toString and equals. The toString method uses
> >>commons.lang.ToStringBuilder to build the toString, and
> >>commons.lang.EqualsBuilder to perform the equals
> comparison. I know it
> >>needs hashCode, I just haven't taken the time to add it yet.
> >>
> >>Is there any interest in having this class donated to
> >>commons-beanutils?
> >>
> >
> >
> > Conceptually, I like the idea. My only concern is that it would
> > introduce a dependency on commons-lang that does not
> currently exist
> > in beanutils.
> >
> >
> >>Steven Caswell
> >
> >
> > Craig
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> --
> :) Christoph Reck
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] extending BasicDynaBean with toString, equals, and
hashCode
Posted by Ch...@dlr.de.
The concept of ToStringBuilder and EqualsBuilder ist good, but not
completely suited for BeanUtils - the reflection pattern used does
not consider the accessor methods for beans.
If your extended dynabean does the explicit use of the lang.builder
code w/o the reflection parts, it should suite the bean use pattern.
A dependency of beanutils on lang will need acceptance voting from
the committers (to me seems to be OK, since lang is even lower level
than beans).
It might be sensible to factor out parts from the lang.builder
implementations to be then subclassed once for beans and once for
full filed reflection usage?
Just my 2c!
Craig R. McClanahan wrote:
>
> On Tue, 3 Jun 2003, Steven Caswell wrote:
>
>
>>Date: Tue, 3 Jun 2003 20:32:26 -0400
>>From: Steven Caswell <st...@caswell.name>
>>Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
>> steven@caswell.name
>>To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>Subject: [beanutils] extending BasicDynaBean with toString, equals,
>> and hashCode
>>
>>I've written an extended dynabean class that extends (actually, wraps)
>>BasicDynaBean to add toString and equals. The toString method uses
>>commons.lang.ToStringBuilder to build the toString, and
>>commons.lang.EqualsBuilder to perform the equals comparison. I know it needs
>>hashCode, I just haven't taken the time to add it yet.
>>
>>Is there any interest in having this class donated to commons-beanutils?
>>
>
>
> Conceptually, I like the idea. My only concern is that it would introduce
> a dependency on commons-lang that does not currently exist in beanutils.
>
>
>>Steven Caswell
>
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
:) Christoph Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [beanutils] extending BasicDynaBean with toString, equals, and
hashCode
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 3 Jun 2003, Steven Caswell wrote:
> Date: Tue, 3 Jun 2003 20:32:26 -0400
> From: Steven Caswell <st...@caswell.name>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> steven@caswell.name
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: [beanutils] extending BasicDynaBean with toString, equals,
> and hashCode
>
> I've written an extended dynabean class that extends (actually, wraps)
> BasicDynaBean to add toString and equals. The toString method uses
> commons.lang.ToStringBuilder to build the toString, and
> commons.lang.EqualsBuilder to perform the equals comparison. I know it needs
> hashCode, I just haven't taken the time to add it yet.
>
> Is there any interest in having this class donated to commons-beanutils?
>
Conceptually, I like the idea. My only concern is that it would introduce
a dependency on commons-lang that does not currently exist in beanutils.
>
> Steven Caswell
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org