On Tue, 16 Oct 2018 16:55:02 -0700, Eric Barnhill wrote:
> The Fraction class is IMO looking good (in better shape than
> in) and is already quite close to fulfilling the standards for a
> Equals() and CompareTo() are well designed and consistent. I see
> missing steps. The easy one is a parse() method which mirrors the
> toString() method. The harder one is the wide range of public
> To be a VALJO all constructors must be private and accessed with
> 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)
> fromDouble(double value, double epsilon, int maxIterations)
> public Fraction(double value,int maxDenominator) -> public
> (double value,int maxDenominator)
> public Fraction(int value) -> public fromInt(int value)
> public Fraction(int num, int denom) -> public fromInt(int num, int
Why not call them all "of(...)" ?
> so this is what I propose to go with.
> If disambiguation in the double cases is still a problem, the
> third of the double constructors could be fromDoubleEpsMaxInt and
> fromDoubleMaxDenom .
> On Thu, Oct 11, 2018 at 7:00 AM Gilles
>> On Wed, 10 Oct 2018 16:18:50 -0700, Eric Barnhill wrote:
>> > I am interested in moving forward on making the Fraction
>> > VALJOs
>> > [NUMBERS-75].
>> > Just a preliminary question for now, are we otherwise happy
>> > Fraction class in the context of commons-numbers? Or should I
>> > around
>> > for any odd behaviors leftover from commons-math (Complex had a
>> > 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").
>> > Eric