Number::Fraction

[Dave Cross]

Quoting "Th. J. van Hoesel" <th.j.v.hoesel at gmail.com>:

>
> Op 3 mei 2013, om 10:21 heeft Dave Cross het volgende geschreven:
>
>> Quoting "Th. J. van Hoesel" <th.j.v.hoesel at gmail.com>:
>>
>>> to me, it would make sense for 3 parameters:
>>>
>>> Number::Fraction->(int, num, den);
>>>
>>> but that would be helpful to work with the so called vulgar  
>>> fractions and cold write things like:
>>> my $twothreefourth = Number::Fraction->new( 2, 3, 4);
>>
>> I think we're starting to get quite close to an area where  
>> positional parameters are potentially confusing.
>>
>>  Number::Fraction->new(1, 2); # num = 1, den = 2
>>  Number::Fraction->new(1, 2, 3) # int = 1, num = 2, den = 3
>
> Positional Parameters can be  a disaster, I know. But sticking to  
> these THREE positional parameters max looks to me not impossible for  
> the user. Also, Math::Fraction utilizes the same schema.
>
> Basically it would do the things below
>
> 1 parameter ----> integer
> and will be handled as @_[0] ÷ 1
> 2 parameter ----> fraction
> will be handled as @_[0] ÷ @_[1]
> 3 parameter ----> mixed
> will become { @_[0] × @_[2]   +  @_[1]  } ÷ @_[2]
>
> and yes, that above is a bit nasty written, for there are quite a  
> bit of 'exceptions' to handle --- and especially the 1-parameter  
> version will have to deal with strings or references

Yes. But positional parameters that change their meaning as you add  
another parameter to the *front* of the list. That sounds a little  
scary to me. Or am I being paranoid?

>> I would probably think seriously about using named parameters here
>>
>>  Number::Fraction->new(numerator => 1, denominator => 2);
>>  Number::Fraction->new(integer => 1, numerator => 2, denominator => 3);
>
> Bu t you will then have to invent a way to remain backward  
> compatible an maintain both ways

Moose makes that easy.

>> Of course, the fact that the names of the parameters are so long  
>> really counts against you here, so you'd want to allow aliases -  
>> int, den & num.
>>
>> In fact, it probably makes sense to move it all to Moose (or Moo, at least).
>
> Noooooooo! it was so simple to use

I'm not sure why you think that adding Moose will make it harder to use.

There's a branch on github which uses Moose.

   https://github.com/davorg/number-fraction/tree/moose

Everything works pretty much the same way that it did before. All the  
existing tests still pass.

>>> can I drop other cases or do you prefer to allow method calls with  
>>> unlimited number of parameters ???
>>
>> You need to deal with idiots who ignore the documentation and call  
>> the methods with the incorrect parameters. Currently, if you call  
>> new() with more than two parameters, the extra ones are just  
>> silently ignored. I think I like that option best, but I wouldn't  
>> object if the constructor just died instead.
>
> I'd prefer to let anything die that does not comply with the  
> supplied interface or API.

Like I said. I really wouldn't object to that. But you still need to  
check for it. In the Moose branch, many invalid parameter combinations  
now die (not all of them yet).

> One thing I was a bit worried about is the fact you accept  
> denominators equal to ZERO ---- Arghhh!. Although totally insane,  
> it's not 'your' fault that division by zero is illegal. Let perl die  
> because of that fact, not the Fraction Module.

Relying on Perl's built-in error checking whenever possible sounds  
sensible to me.

>> p.s. This conversation would be much easier to follow if we all  
>> used the same quoting style :-/
>
> better ? :-)

Much better. Thanks :)

Dave...