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>
Date: Sun, 17 Aug 2003 15:39:23 -0400 (EDT)
From: Henri Yandell <bayard@generationjava.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [lang] .lang.math (WAS: Words - for 2.0)
In-Reply-To: <001c01c364ed$f48835e0$5f3e8051@oemcomputer>
Message-ID: <Pine.LNX.4.44.0308171535400.21840-100000@umbongo.flamefew.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


My fault for starting this :)

I can see that over time a balance between lang and math would occur. If
lang.math had too much in [ie) is Range really common enough etc etc] then
it would deprecate in favour of [math].

Ditto for [text]. If we include Word* stuff now, then later when [text] is
mature we can deprecate in favour of it. The main point being, let's not
hold code back just because there might be a project to hold it in a year.
It is better for users and for that project itself to have the basic text,
math, reflect, whatever code in lang and hand it over later.

It's much like how we'd expect other Apache projects to work. They write
their own util stuff, but over time it becomes obvious that it's better
placed in Lang and they work out a plan to migrate to ours. Exactly as
Henning wants to do with WordWrap, if it can be ready.

Hen

On Sun, 17 Aug 2003, Stephen Colebourne wrote:

> Doesn't work like that :-)
>
> [math] is a very large mathematics/statistics package. This is suited to
> mathematical or statistical analysis.
>
> [lang].math is a small convenient addition to the JDK. It contains classes
> that should be in the JDK, such as number ranges and fraction. These will
> always form part of [lang] IMO.
>
> Stephen
>
>
> ----- Original Message -----
> From: "Gary Gregory" <ggregory@seagullsw.com>
> > Resending.
> >
> > Since we are on the topic of things in the wrong place... I'll raise
> another
> > "arg" and ask: Why have an o.a.c.lang.math when we have a o.a.c.math in
> the
> > works? If o.a.c.lang.math is really useful, why not move it to o.a.c.math?
> >
> > If you used the now deprecated range classes, you /should/ change your
> code
> > to .lang.math. Hmm, maybe this is something we could do for 2.1/3.0.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > > Sent: Saturday, August 16, 2003 10:05
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [lang] Words - for 2.0
> > >
> > > So, not too aarggh then, just pull WordWrapUtils ;-))
> > >
> > > (The other stuff this morning was all javadoc except for ToStringStyle
> > > where
> > > a method rename took place with deprecation)
> > >
> > > Stephen
> > >
> > > ----- Original Message -----
> > > From: "Henri Yandell" <bayard@generationjava.com>
> > > To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> > > Sent: Saturday, August 16, 2003 5:56 PM
> > > Subject: Re: [lang] Words - for 2.0
> > >
> > >
> > > >
> > > >
> > > > On Sat, 16 Aug 2003, Stephen Colebourne wrote:
> > > >
> > > > > In examining the release, I found I need to annoy everyone again.
> > > >
> > > > *aarggh* :)
> > > >
> > > > > WordWrapUtils is broken.
> > > >
> > > > No no no. It's a feature.
> > > >
> > > > > The algorithm relies on a newLineChars parameter that is used for
> two
> > > > > purposes.
> > > > > 1) Splitting the input string
> > > > > 2) Adding newlines to the output string
> > > > >
> > > > > This is a new class, so it should either be pulled (preferred) or
> > > fixed
> > > (not
> > > > > preferred, as there are various issues)
> > > >
> > > > +1 to pulled out for consideration for 2.1/other.
> > > >
> > > > > Related issue - WordWrapUtils is too specific a name.
> > > > > I propose:
> > > > > 1) changing it to WordUtils (or StringWordUtils)
> > > >
> > > > +1 on WordUtils. More generic.
> > > >
> > > > > 2) moving capitalizeAllWords to WordUtils
> > > > > 3) moving uncapitalizeAllWords to WordUtils
> > > > > 4) moving swapCase to WordUtils
> > > >
> > > > +1 for 2.1/3.0.
> > > >
> > > > > This would help reduce the size of StringUtils, and provide much
> > > better
> > > > > functional grouping. There is lots we can do with words. (Of course
> > > you
> > > > > could argue for a separate [text] project, but I doubt there is that
> > > much.)
> > > >
> > > > -1 to [text] taking the above until [text] is ready for 1.0. I am +1
> for
> > > a
> > > > [text], in the same way I'm +1 for [math], but I don't want us to
> > > > deprecate our methods until [math] releases at 1.0 with our methods
> > > > included.
> > > >
> > > > > I would like to do this for 2.0, as otherwise users of
> > > capitaliseAllWords
> > > > > will have to change twice. However we could say that is a small
> group
> > > of
> > > > > people and postpone the change to 2.1.
> > > > >
> > > > > Opinions?
> > > >
> > > > There are going to be changes on the new features before 2.1/3.0, and
> > > > it's going to be a year probably until we have a 3.0 out [though 2.0.1
> > > or
> > > > 2.1 might be quicker]. I may be being lazy, but I don't think that
> going
> > > > with WordUtils right now would affect too many people and we don't
> > > really
> > > > have enough knowledge right now to get it right for 2.0.
> > > >
> > > > Hen
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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