Yes, I think its better to wait until [math] has matured before making any decisions about what to keep in lang and what to depricate. I really think your point about not "holding code back" is a valid and powerfull statement. We have plenty of "future" to work through the details of consolidation once we've reached maturity.

But thats not to suggest that the subject shouldn't be "tabled" from time to time, just as a measure of "calibration" between the two projects.

It seems the case that [math] will always be dependent on [lang] and not the other way around. I think there should be some discussion about what math needs to use that may already be available in [lang]. As well it would be wise to do the same with [collections]. I suspect that [math] will always be hierarchically dependent on these packages.

-Mark

Henri Yandell wrote:

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" <[EMAIL PROTECTED]>

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:[EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to