[lang] 1.0 release foci

[Henri Yandell <ba...@generationjava.com>]

[Oops, I meant to send this on Sunday night]

My wife's stay in hospital is coming to an end [ended now! woo], so I have
some time to think again. So I thought I'd start with a list of the things
we're focusing on before a 1.0 release,, let me know any I miss or errors
I have.

1) Reflection code. This is still up in the air with ClassUtils waiting
in the wings. I need to commit ClassUtils into the top dir in sandbox.lang
so people can have easy access to it.

2) Enum. Stephen submitted his code ideas to the sandbox. Opinions are
needed etc.

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.

4) ExceptionUtils. Some comments from Costin are directing us to the fact
that the exception sub-package needs enhancement. [Some work has been
commited on this, there are a lot of suggestions over the mail list that
need collating]

5) StringUtils. Prior to my emergency, I was looking into all String Utils
packages in the Jakarta CVS. I aim to continue that and continue to suck
anything useful out of them. In fact I want to find anything with 'Util'
or 'Helper' in the name, but that takes a little while :) [And of course
there's the public() to figure out now]

6) NumberRange. I looked into adding some operations from an Interval
class of mine [which came from a Lisp book a while back] and need to
email with the strategies to see if anyone agrees.
  Part of this saw me add a min(double[]) and max(double[]) set of
methods to NumberUtils. Are these [and other primitives I guess?] of
interest?

7) Util.CalendarUtils. There was some suggestion that some time based code
might make its way into Lang. Am unsure where that all ended up, I know
CalendarUtils seemed to be on its way into Util for the time being. Any
other Util classes which are deemed of interest to Lang would be worth
considering now. It's mainly flotsam.

....

That's as far as I got on Sunday. Any other things?

Hen



--
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]

[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]

[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>

[lang] HashCodeUtils [was 1.0 release foci]

[Stephen Colebourne <sc...@btopenworld.com>]

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] 1.0 release foci

[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.
-- 

Daniel Rall <dl...@finemaltcoding.com>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] 1.0 release foci

[Stephen Colebourne <sc...@btopenworld.com>]

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.

It actually only causes an issue if you put objects of different types in to
a HashMap (or equivalent). Generally, all the keys in a hashmap are of the
same type, so its not an issue.

Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] 1.0 release foci

[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.
-- 

Daniel Rall <dl...@finemaltcoding.com>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] 1.0 release foci

[Daniel Rall <dl...@finemaltcoding.com>]

Henri Yandell <ba...@generationjava.com> writes:

> 4) ExceptionUtils. Some comments from Costin are directing us to the fact
> that the exception sub-package needs enhancement. [Some work has been
> commited on this, there are a lot of suggestions over the mail list that
> need collating]

I will take responsibility for this.  I was hoping on getting some
more comments on implementation strategy, but I'll just proceed with
what I think is the right course and will have something to commit
within the week (probably sooner rather than later).
-- 

Daniel Rall <dl...@finemaltcoding.com>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>