Fraction in o.a.c.m. implements the FieldElement interface, which I can't imagine moving to Lang.
On Tue, Jun 28, 2016 at 6:31 AM, Gilles <gil...@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.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 > >
