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