commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [numbers] Making fractions VALJOs
Date Wed, 17 Oct 2018 00:56:00 GMT
On Tue, 16 Oct 2018 16:55:02 -0700, Eric Barnhill wrote:
> 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)

Why not call them all "of(...)" ?

Gilles

>
> 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 <gilles@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message