I’m going to have a go at the implementation here. I figure we can talk more about it after we have a proposed solution in place.
-Rob > On Jun 28, 2016, at 7:29 AM, Gilles <gil...@harfang.homelinux.org> wrote: > > 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 <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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
