osdir.com


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

Re: [numbers] Making fractions VALJOs


On Wed, 17 Oct 2018 16:33:58 -0700, Eric Barnhill wrote:
Oh right, that is the convention. I knew there was something off.

As far as you understand, is to within VALJO standards to overload factory
methods,

I don't think that it is ValJO-related; method overload is a
feature, so better use it rather than duplicate what the compiler
can do by itself. ;-)

Gilles

so long as they are not private constructors? All that is
specified on the page is that VALJOs must have all constructors private. So I am not sure whether it is in the spirit of VALJOs to overload, but coming
up with elaborate names for each constructor doesn't seem like a very
streamlined coding practice.

On Tue, Oct 16, 2018 at 5:56 PM Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx> wrote:

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@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