commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [lang] Divesting the commons.lang.math package
Date Mon, 11 Jan 2010 23:17:59 GMT
Divest? I object to removing Fraction from [lang], as its a very core 
concept tat is missing from the JDK. And thee are many users who would 
just want Fraction and none of the rest of the [math] library.

The [lang] maths package is fo non-mathematicians. The [math] library is 
for serious mathematicians. Big difference.

As per the commons charter, there is nothing wrong with having 
duplicated code/concepts in Commons.

Stephen

Paul Benedict wrote:
> Without any further input (over a week), I say it's safe to divest.
> 
> On Sun, Jan 3, 2010 at 5:58 AM, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
>> Henri Yandell a écrit :
>>> On Sat, Jan 2, 2010 at 1:57 PM, Paul Benedict <pbenedict@apache.org> wrote:
>>>> This is how I believe the commons.lang.math package can be eliminated.
>>>> Based on the current 3.0-SNAPSHOT API, there are only three classes
>>>> left:
>>>>
>>>> Fraction
>>>> IEEE754rUtils
>>>> NumberUtils
>>>>
>>>> 1) Fraction should leave; it is completely inappropriate for this
>>>> library. It has nothing to do with the JDK or supporting the Java
>>>> language. It belongs squarely in Commons Math.
>>>> 2) IEEE754rUtils should move to the root of commons.lang
>>>> 3) NumberUtils should move to the root of commons.lang
>>> We discussed Fraction being deleted earlier in 3.0, but the view was
>>> to keep it. I'm happy for it to go. [math]'s version appears to be
>>> practically the same.
>>>
>>> Half of NumberUtils is String conversion. The other half are min/max;
>>> which is what IEEE754Utils is. These could potentially move to
>>> [math]'s util.MathUtils.
>>>
>>> One advantage is that people looking for these minor methods would
>>> have an on ramp into the other components for the more powerful
>>> features.
>>>
>>> One concern I have is finding the basic functionality in another
>>> package. You go to [math] and it's all about the powerful deep things,
>>> not a random reusable bit of code off to the side.
>>>
>>> Maybe the right solution there is "Commons Common", with 80% reuse/20%
>>> power; or maybe the solution is documentation in which all the basic
>>> types of methods are collated and link to the components they're in.
>> We probably lack good documentation on the basic utility parts in [math].
>>
>> Luc
>>
>>> Hen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message