On Mon, 27 Jun 2016 17:21:40 -0700, Gary Gregory wrote:
On Mon, Jun 27, 2016 at 4:55 PM, Ralph Goers
<ralph.go...@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 <gil...@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.wor...@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.go...@dslextreme.com>
>>> wrote:
>>>
>>>>
>>>> > On Jun 27, 2016, at 11:47 AM, Jochen Wiedmann <
>>>> jochen.wiedm...@gmail.com> wrote:
>>>> >
>>>> > On Sun, Jun 26, 2016 at 10:30 PM, Gilles <
gil...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
