Number::Fraction

[Th. J. van Hoesel]

Op 3 mei 2013, om 12:34 heeft Dave Cross het volgende geschreven:

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

Maybe you are not... but that is up to you to decide ;-)

This morning I woke up and realised that maybe here can be some risk...

What if people figured out that the method did accept 3 or more arguments (why and how.. because they dug into the code ?). It would make no sensense at all to call the method Number::Fraction->new( 1, 4, 6, 7, 2), but it would produce by some magic allowance that it should return a Number::Fraction object.

So, now we have some legacy code. And now extending the functionality in a natural understandable manner, might cause old programs that did very odd method calls to break.


Is my next approach acceptable:

now:
a quick patch that will issue a warning the moment the method is being called with 3 or more arguments (only once per application run), letting users know that they did some odd thing, but forgive them and continue.

next:
implement a 3-argument methode that will only work properly when the modules is being used as
use Number::Fraction qw{:mixed}
still issue a warning

next:
let the module die with unintended 3-plus-argument calls
use Number::Fraction qw{:mixed}

next:
drop the requirement to use :mixed, make it default


all in a time frame of one year ?



Someone really need to enlighten me as to why write method implementations like this, that accept arbitrary arguments, rather than locking down the API

It's great to learn from the Old and Wise Monks - thanks!

Greetings Theo

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