[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [numbers] Making fractions VALJOs

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 .


On Thu, Oct 11, 2018 at 7:00 AM Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx