Op 3 mei 2013, om 12:34 heeft Dave Cross het volgende geschreven:
> Quoting "Th. J. van Hoesel" <th.j.v.hoe...@gmail.com>:
>
>>
>> Op 3 mei 2013, om 10:21 heeft Dave Cross het volgende geschreven:
>>
>>> Quoting "Th. J. van Hoesel" <th.j.v.hoe...@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?
Yes, you are :-)
it's just a matter of making sure that the 2-parameter version keeps doing what
it is supposed to be doing and making the 3-parameter version do what we humans
are familiar with... with mixed or vulgar fractions, we use the first number as
the integer part.
You are probably right, when allowing previous version to pass in any number
off arguments and only considering the first two as being useful - you might
start thinking that any expansion of the method and the number off parameters
being used should pick-up after the first two commonly used parameters... I
would agree in those situations....
But isn't that what the whole overloading is all about, referring to your
introduction of the republished article you mentioned before. Doing one thing
when passing in a reference, doing another thing when passing in a string, and
a complete different thing when passing in parameters ?
>>> 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.
fine... lets rephrase myself
Nooooooo! it was so simple to implement, just core perl, no nothing modern Perl.
>>>> 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.
I'll refrain myself from doing sanity checks for the NoMoose version, keeping
it as it has been as much as possible.
I was tempted to delve into the 'power raise' part. For -15_5/8 ^ -1/3 == -2/5
But even that is something that would go beyond the purpose of updating the
Number::Fraction module
>>> p.s. This conversation would be much easier to follow if we all used the
>>> same quoting style :-/
>>
>> better ? :-)
>
> Much better. Thanks :)
>
> Dave...
>
>
>
