Re: Number::Fraction

[Th. J. van Hoesel]

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);

can I drop other cases or do you prefer to allow method calls with unlimited 
number of parameters ???

Theo

Op 2 mei 2013, om 19:50 heeft Th. J. van Hoesel het volgende geschreven:

> That was a very clear explenation!.
> 
> the :constants is some heavy powerlifting for the compiler/interpreter. btw, 
> what happens if more modules would do that. Is the interpeter just passing 
> every bit of string to all the subs reference in that hash ? can two modules 
> grab the same data and mess up the thing? will only the first in the hash 
> been used? will they be nested, who comes first ?
> 
> First I was a bit confused at what all the different branchings were about in 
> the constructor, but now I see where they are comming from... and why needed.
> 
> Back to your code, line 198:
> 
>   if (@_ >= 2)
> 
> Why not check for 
> 
>   if (@_ == 2)
> 
> ?
> 
> it should have only two arguments to construct a fraction from calling 
> Number::Fraction->new(1, 2);
> 
> Why would you allow it to pass other arguments?
> 
> 
> Op 2 mei 2013, om 15:22 heeft Dave Cross het volgende geschreven:
> 
>> Quoting "Th. J. van Hoesel" :
>> 
>>> However, can someone point me out what is happening between lines 132 and 
>>> 144 of Fraction.pm ? This part is the neatest part of the module, where it 
>>> enables the module to use constants in your Perl programs.
>> 
>> I don't know if it's any help, but I've just rediscovered (and republished) 
>> the article that I wrote explaining how Number::Fraction works.
>> 
>>  http://perlhacks.com/articles/perl-com/overloading-perl-objects/
>> 
>> Cheers,
>> 
>> Dave...
> 

Re: Number::Fraction

[Dave Cross]

Quoting "Th. J. van Hoesel" :


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

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);

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

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.


Cheers,

Dave...

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

Re: Number::Fraction

[Th. J. van Hoesel]

Op 3 mei 2013, om 10:21 heeft Dave Cross het volgende geschreven:

> Quoting "Th. J. van Hoesel" :
> 
>> 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

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

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

N! it was so simple to use

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

Read the POD

Yes, I know:
be tolerant to what to consume and be strict in what you produce

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.

> Cheers,
> 
> Dave...
> 
> p.s. This conversation would be much easier to follow if we all used the same 
> quoting style :-/
> 


better ? :-)

Re: Number::Fraction

[Dave Cross]

Quoting "Th. J. van Hoesel" :



Op 3 mei 2013, om 10:21 heeft Dave Cross het volgende geschreven:


Quoting "Th. J. van Hoesel" :


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


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

Re: Number::Fraction

[Th. J. van Hoesel]

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

> Quoting "Th. J. van Hoesel" :
> 
>> 
>> Op 3 mei 2013, om 10:21 heeft Dave Cross het volgende geschreven:
>> 
>>> Quoting "Th. J. van Hoesel" :
>>> 
 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).
>> 
>> N! 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


Nooo! 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 
>>

[no subject]

[Christine Wong]

Hello!

Hope everyone enjoyed themselves last night at the Perl meet up.

It was a very enjoyable experience for me.

For those who didn't get my contact details I am reachable on my email addy: 
christine.w...@squareoneresources.com
 and my number is 0207 665 5813/0788 229 3884.

Please feel free to contact me if you are 1. Looking for new opportunities or 
2. Looking to hire :) 3. Just want a quick chat/catch up.

All calls and communication will be kept strictly private & confidential.

Kind regards,


christine wong | digital media permanent consultant

t: +44 (0)20 7208 2828 | ddi: +44 (0)20 7665 5813 | m: +44 (0)7738 488572
square one resources | 6 devonshire square | london | ec2m 4ye | united kingdom

christine.w...@squareoneresources.com
 | www.squareoneresources.com

Re:

[Joel Bernstein]

The jobs list is --> that way.


On 3 May 2013 10:18, Christine Wong
wrote:

> Hello!
>
> Hope everyone enjoyed themselves last night at the Perl meet up.
>
> It was a very enjoyable experience for me.
>
> For those who didn't get my contact details I am reachable on my email
> addy: christine.w...@squareoneresources.com christine.w...@squareoneresources.com> and my number is 0207 665
> 5813/0788 229 3884.
>
> Please feel free to contact me if you are 1. Looking for new opportunities
> or 2. Looking to hire :) 3. Just want a quick chat/catch up.
>
> All calls and communication will be kept strictly private & confidential.
>
> Kind regards,
>
>
> christine wong | digital media permanent consultant
>
> t: +44 (0)20 7208 2828 | ddi: +44 (0)20 7665 5813 | m: +44 (0)7738 488572
> square one resources | 6 devonshire square | london | ec2m 4ye | united
> kingdom
>
> christine.w...@squareoneresources.com christine.w...@squareoneresources.com%20> | www.squareoneresources.com<
> http://www.squareoneresources.com>
>
>
>
>
>

Re:

[Nicholas Clark]

On Fri, May 03, 2013 at 04:04:18PM +0200, Joel Bernstein wrote:
> The jobs list is --> that way.

I assume that Tom will contradict me if he feels that I am wrong here,
but I thought that it was perfectly reasonable for someone who sponsored
a social with a considerable sum to be permitted to mail the main list to
say thank you for an enjoyable evening.

I would hope that recruiters and firms would continue to think that
sponsoring london.pm events is a worthwhile investment to increase leads.
A reaction of "thanks, but sod off" isn't likely to encourage this.

I'd like to thank Christine Wong for sponsoring the social.

(Even though I wasn't able to attend, now being somewhat further from
London than most people on the list. Because I like the idea of "free beer"
and would like to see it happen more often.)

Nicholas Clark

Re:

[Leo Lapworth]

On 3 May 2013 15:16, Nicholas Clark  wrote:
>
> I would hope that recruiters and firms would continue to think that
> sponsoring london.pm events is a worthwhile investment to increase leads.
> A reaction of "thanks, but sod off" isn't likely to encourage this.
>
> I'd like to thank Christine Wong for sponsoring the social.
>

Totally agree.

And as I'm here I'd like to mention how helpful Christine has been when
I've been looking for a perl developer.

Leo

Re:

[DAVID HODGKINSON]

On 3 May 2013, at 15:04, Joel Bernstein  wrote:

> The jobs list is --> that way.
> 


Berlin.pm is --> that way.

Re:

[Pierre M]

Hi David,

what solution did you choose for your throttled API?

Did you try Schedule::AdaptiveThrottler ?

I know i'll need to do something similar in the next few months, i've
just been pushing it off.

On 3 May 2013 15:38, DAVID HODGKINSON  wrote:
>
> On 3 May 2013, at 15:04, Joel Bernstein  wrote:
>
>> The jobs list is --> that way.
>>
>
>
> Berlin.pm is --> that way.
>
>

Re:

[Pierre M]

oops, was meant to be only sent to David, sorry.

On 3 May 2013 16:45, Pierre M  wrote:
> Hi David,
>
> what solution did you choose for your throttled API?
>
> Did you try Schedule::AdaptiveThrottler ?
>
> I know i'll need to do something similar in the next few months, i've
> just been pushing it off.
>
> On 3 May 2013 15:38, DAVID HODGKINSON  wrote:
>>
>> On 3 May 2013, at 15:04, Joel Bernstein  wrote:
>>
>>> The jobs list is --> that way.
>>>
>>
>>
>> Berlin.pm is --> that way.
>>
>>

Re:

[Joel Bernstein]

*grin* I laughed.


On 3 May 2013 16:38, DAVID HODGKINSON  wrote:

>
> On 3 May 2013, at 15:04, Joel Bernstein  wrote:
>
> > The jobs list is --> that way.
> >
>
>
> Berlin.pm is --> that way.
>
>
>
>