The Fraction class is IMO looking good (in better shape than Complex was in) and is already quite close to fulfilling the standards for a VALJO. Equals() and CompareTo() are well designed and consistent. I see two missing steps. The easy one is a parse() method which mirrors the toString() method. The harder one is the wide range of public constructors.
To be a VALJO all constructors must be private and accessed with static factory methods. If these factory methods themselves can be overloaded, I think a decent schema emerges: current constructor -> proposed factory method -------------------------------------------------------- public Fraction(double value) -> public fromDouble(double value) public Fraction(double value, double epsilon, int maxIterations) -> public fromDouble(double value, double epsilon, int maxIterations) public Fraction(double value,int maxDenominator) -> public fromDouble (double value,int maxDenominator) public Fraction(int value) -> public fromInt(int value) public Fraction(int num, int denom) -> public fromInt(int num, int denom) so this is what I propose to go with. If disambiguation in the double cases is still a problem, the second and third of the double constructors could be fromDoubleEpsMaxInt and fromDoubleMaxDenom . Eric On Thu, Oct 11, 2018 at 7:00 AM Gilles <gil...@harfang.homelinux.org> wrote: > On Wed, 10 Oct 2018 16:18:50 -0700, Eric Barnhill wrote: > > I am interested in moving forward on making the Fraction classes > > VALJOs > > [NUMBERS-75]. > > > > Just a preliminary question for now, are we otherwise happy with the > > Fraction class in the context of commons-numbers? Or should I look > > around > > for any odd behaviors leftover from commons-math (Complex had a lot > > of > > those) that might also be improved? > > AFAIK, there was no in-depth review as was done for "Complex". > So it would indeed be quite useful to check what the Javadoc > states, whether it seems acceptable (wrt what other libraries > do), and whether the unit tests validate everything. > > Side note: Unless I'm overlooking something, completing this > task will result in getting rid of all the formatting and > "Locale"-related classes (as for "Complex"). > > Best, > Gilles > > > > > Eric > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
