commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [DISCUSS] "Fraction" also in Commons Lang (Was: [VOTE] New component: Rational numbers)
Date Tue, 28 Jun 2016 11:29:22 GMT
On Tue, 28 Jun 2016 07:05:25 -0400, Matt Adereth wrote:
> Fraction in o.a.c.m. implements the FieldElement interface, which I 
> can't
> imagine moving to Lang.

IMO, this adds to having a standalone component that can cater for 
simple
and advanced usage.  [E.g. casual use would refer to "Fraction" 
(without
needing to be aware of the base class).]


Gilles

> On Tue, Jun 28, 2016 at 6:31 AM, Gilles 
> <gilles@harfang.homelinux.org>
> wrote:
>
>> On Mon, 27 Jun 2016 17:21:40 -0700, Gary Gregory wrote:
>>
>>> On Mon, Jun 27, 2016 at 4:55 PM, Ralph Goers 
>>> <ralph.goers@dslextreme.com>
>>> wrote:
>>>
>>> Your reading and mine are a bit different. Stephen Colebourne 
>>> wanted
>>>> Fraction kept in Commons Lang as he felt users would find more 
>>>> value in
>>>> it
>>>> there because Commons Math is too specialized.
>>>>
>>>
>> He did not seem to have to depend on (a huge, specialized) CM just 
>> to use
>> the fraction concept.
>>
>> A standalone component fills that bill, while providing the 
>> advantage that,
>> by the same argument, other developers might not wish to depend on a 
>> huge
>> CL
>> just to get that functionality.
>>
>> I read Gary’s comment as a
>>>> rebuttal to the person who said Fraction was “foundational” for 
>>>> Commons
>>>> Math.  No one ever suggested Fraction deserved to be its own 
>>>> project.
>>>>
>>>
>> That would have been the common denominator.
>> I strongly suspect that no one suggested because they did not want 
>> "their"
>> library to depend on a "external" component. [This is all moot (to 
>> say the
>> least) given that the dependency would be towards a Commons 
>> library!]
>>
>> From a developer POV, it does not make sense to maintain two 
>> packages
>> with the exact same purpose.
>>
>> After looking at both Lang and Math my feeling is that Fraction is 
>> simply
>>>> too small to warrant being a project on its own.
>>>>
>>>
>> Not a full-fledged "project", just a Commons component.
>>
>> How do get to that feeling?  Is there a way to make a workable rule 
>> for
>> creating synergies rather than use up the resources on overlapping 
>> codes?
>>
>> Does what is in Commons
>>>> Math really provide any value over what is in Commons Lang? If so,
>>>> perhaps
>>>> the Fraction support in Commons Lang should just be enhanced.
>>>>
>>>
>> One of the options which I suggested.
>>
>> But since people preferred to duplicate functionality rather than 
>> join
>> forces
>> on a common package, it is now additional work to check whether both
>> packages
>> provide the same value, or how they should be merged.
>>
>> From my Smalltalk days, I fondly recall Smalltalk's Fraction [1] 
>> being a
>>> basic object like Integer, very cool. So yeah, it could happily 
>>> live as a
>>> first class citizen in Commons Lang AFAIC. But what I do not want 
>>> to
>>> decide
>>> when I am coding up an app, is which Fraction to use, the one from 
>>> Commons
>>> Foo, Commons Bar or FooBar. I want one well maintained class I can 
>>> rely
>>> on.
>>>
>>
>> And how to judge which implementation is more reliable?
>> And if you arrived at a reasoned choice, why allow unsuspecting 
>> users to
>> make the wrong choice?
>> And if both are of equal value, why have two???
>>
>> Gilles
>>
>>
>>
>> [1]
>>>
>>>
>>> 
>>> https://chara.cs.illinois.edu/sites/cs528/files/arithmetic-and-double-dispatching-in-smalltalk-80.pdf
>>>
>>> Gary
>>>
>>>
>>>> Ralph
>>>>
>>>> > On Jun 27, 2016, at 3:51 PM, Gilles 
>>>> <gilles@harfang.homelinux.org>
>>>> wrote:
>>>> >
>>>> > On Mon, 27 Jun 2016 16:34:47 -0500, Brent Worden wrote:
>>>> >> One previous thread on the subject:
>>>> >> http://markmail.org/message/u7lcxd6ye6qnesku <
>>>> http://markmail.org/message/u7lcxd6ye6qnesku>
>>>> >
>>>> > The final sentence of that thread:
>>>> > "So I do not see Fraction as the foundation for anything really.
>>>> >  It stands on its own nicely IMO."
>>>> >
>>>> > What more adequate conclusion would be than to have a standalone
>>>> > Commons component?
>>>> >
>>>> > [And the majority of the thread participants seemed to agree.
>>>> > Yet the inertia prevailed.]
>>>> >
>>>> > Gilles
>>>> >
>>>> >> Brent
>>>> >>
>>>> >> On Mon, Jun 27, 2016 at 4:04 PM, Brent Worden 
>>>> <brent.worden@gmail.com
>>>> >
>>>> >> wrote:
>>>> >>
>>>> >>> Somewhere in the mailing list archives is a discussion around

>>>> this
>>>> very
>>>> >>> topic.  It was quite some time ago so I do not recall the 
>>>> reasoning
>>>> for
>>>> >>> keeping both at that time.  I will try sifting through the 
>>>> archives
>>>> to
>>>> find
>>>> >>> the thread if I find time.
>>>> >>>
>>>> >>>
>>>> >>> Brent
>>>> >>>
>>>> >>> On Mon, Jun 27, 2016 at 2:47 PM, Ralph Goers <
>>>> ralph.goers@dslextreme.com>
>>>> >>> wrote:
>>>> >>>
>>>> >>>>
>>>> >>>> > On Jun 27, 2016, at 11:47 AM, Jochen Wiedmann <
>>>> >>>> jochen.wiedmann@gmail.com> wrote:
>>>> >>>> >
>>>> >>>> > On Sun, Jun 26, 2016 at 10:30 PM, Gilles <
>>>> gilles@harfang.homelinux.org>
>>>> >>>> wrote:
>>>> >>>> >
>>>> >>>> >> Is it a complete overlap with what is in CM's package
>>>> >>>> >> "o.a.c.m.fraction"?
>>>> >>>> >> Should one be dropped in favour of the other?
>>>> >>>> >
>>>> >>>> > *Can* we drop either, while maintaining BC?
>>>> >>>>
>>>> >>>>
>>>> >>>> Why wouldn’t you be able to. The user would be able to

>>>> continue
>>>> using
>>>> the
>>>> >>>> old version if the need it.
>>>> >>>>
>>>> >>>> Ralph


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


Mime
View raw message