You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/08/15 00:39:49 UTC
[lang] HashCodeUtils [was 1.0 release foci]
From: "Daniel Rall" <dl...@finemaltcoding.com>
> "Stephen Colebourne" <sc...@btopenworld.com> writes:
>
> > From: "Daniel Rall" <dl...@finemaltcoding.com>
> > > Henri Yandell <ba...@generationjava.com> writes:
> > >
> > > > 3) HashCodeUtils. Stephen just submitted this class. Opinions
desired.
> > My
> > > > only one is whether developers are happy for us to make decisions
for
> > > > them, like using 37 as the 'random primary number'. Hopefully
therre's
> > no
> > > > use case for a developer needing control over that.
> > >
> > > I was a bit put off by being "stuck" with 37 myself.
> >
> > The only solution I can think of is to pass the value in as another
> > argument, but that seems kinda messy.
>
> A good use case for a true object, rather than a collection of utility
> methods.
Of course - HashCodeBuilder. But should we offer both HashCodeUtils and
HashCodeBuilder??
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] HashCodeUtils [was 1.0 release foci]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
HashCodeUtils has now become HashCodeBuilder. And its much better as a
result, thanks Daniel.
Stephen
----- Original Message -----
From: "Daniel Rall" <dl...@finemaltcoding.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, August 15, 2002 12:25 AM
Subject: Re: [lang] HashCodeUtils [was 1.0 release foci]
> "Stephen Colebourne" <sc...@btopenworld.com> writes:
>
> > From: "Daniel Rall" <dl...@finemaltcoding.com>
> > > "Stephen Colebourne" <sc...@btopenworld.com> writes:
> > >
> > > > From: "Daniel Rall" <dl...@finemaltcoding.com>
> > > > > Henri Yandell <ba...@generationjava.com> writes:
> > > > >
> > > > > > 3) HashCodeUtils. Stephen just submitted this class. Opinions
> > desired.
> > > > My
> > > > > > only one is whether developers are happy for us to make
decisions
> > for
> > > > > > them, like using 37 as the 'random primary number'. Hopefully
> > therre's
> > > > no
> > > > > > use case for a developer needing control over that.
> > > > >
> > > > > I was a bit put off by being "stuck" with 37 myself.
> > > >
> > > > The only solution I can think of is to pass the value in as another
> > > > argument, but that seems kinda messy.
> > >
> > > A good use case for a true object, rather than a collection of utility
> > > methods.
> >
> > Of course - HashCodeBuilder. But should we offer both HashCodeUtils and
> > HashCodeBuilder??
>
> I would prefer to have just one; it keeps the API narrower, which
> generally greatly increases usability.
> --
>
> Daniel Rall <dl...@finemaltcoding.com>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] HashCodeUtils [was 1.0 release foci]
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> From: "Daniel Rall" <dl...@finemaltcoding.com>
> > "Stephen Colebourne" <sc...@btopenworld.com> writes:
> >
> > > From: "Daniel Rall" <dl...@finemaltcoding.com>
> > > > Henri Yandell <ba...@generationjava.com> writes:
> > > >
> > > > > 3) HashCodeUtils. Stephen just submitted this class. Opinions
> desired.
> > > My
> > > > > only one is whether developers are happy for us to make decisions
> for
> > > > > them, like using 37 as the 'random primary number'. Hopefully
> therre's
> > > no
> > > > > use case for a developer needing control over that.
> > > >
> > > > I was a bit put off by being "stuck" with 37 myself.
> > >
> > > The only solution I can think of is to pass the value in as another
> > > argument, but that seems kinda messy.
> >
> > A good use case for a true object, rather than a collection of utility
> > methods.
>
> Of course - HashCodeBuilder. But should we offer both HashCodeUtils and
> HashCodeBuilder??
I would prefer to have just one; it keeps the API narrower, which
generally greatly increases usability.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>