Developers of Sympa

[IKEDA Soji <address@concealed>]

Hi,

On Tue, 25 Feb 2014 11:48:01 +0100
David Verdin <address@concealed> wrote:

> Dear all,
> 
> Sorry for delayed answer. I had a lot of operational stuff to do recently.
> 
> Le 24/02/14 14:29, Guillaume Rousse a écrit :
> > Le 18/02/2014 04:33, IKEDA Soji a écrit :
> >>>> Mandatory parameter(s) are put on the beginning of argument list
> >>>> as unnamed values, then optional parameter(s) follow as named
> >>>> values.
> >>>>
> >>>> sub foo {
> >>>>       my $a = shift;
> >>>>       my $b = shift;
> >>>>       my %params = @_;
> >>>>
> >>>>       do_something($a, $b, $params{'c'});
> >>>> }
> >>> Which introduce yet another style, mixing named and positional 
> >>> parameters...
> >>>
> >>> So basically, we have three different style for parameters:
> >>> A) positional parameters
> >>> sub foo {
> >>>      my ($a, $b, $c) = @_;
> >>> }
> >>> foo($a, $b, $c);
> >>>
> >>> B) named parameters
> >>> sub foo {
> >>>      my (%params) = @_;
> >>> }
> >>> foo(arg1 => $a, arg2 => $b, option => $c);
> >>>
> >>> C) mixed parameters
> >>> sub foo {
> >>>      my ($a, $b, %params) = @_;
> >>> }
> >>> foo($a, $b, option => $c);
> >>>
> >>> I guess everyone here will agree than enforcing consistent style is
> >>> desirable. Can we have a quick poll on prefered style among other
> >>> developpers ?
> >>>
> >>> I'm strongly in favor of B, as the most self-describing one. Then A
> >>> (simplest), then C.
> > David, Etienne, Marc, any opinion in this topic
> Definitely!
> 
> I'm in favour of B for clarity AND for not having to wonder the 
> parameters order when calling a sub.
> However, I think it is important to test the presence / absence of 
> expected parameters just after the "my (%params) = @_;" and translate 
> them into local variables. We could even undef the %params hash just 
> after converting its values to local variables.
> That way, if we had a new key/value to the params hash and try to use it 
> directly in the code a $hash{$key}, we woul find the b_ug at compile time.
> 
> So that could turn to:
> 
> B) named parameters
> sub foo {
>       my (%params) = @_;
>      my $email = $params{'email'};
>      my $action = $params{'action'};
>      undef %params;
>      ...
>      do_something($email); # Would work
>      do_something($params{'option'}); # Would issue in strict mode 
> '%params needs to be defined...'
> }
> foo(email => $a, action => $b, option => $c);

I don't understand what is compared by Guillaume's options.
How about follwoing method call?

  $obj->foo( parameters... );

This must not be in case B.

I feel named options preferable, but it may be used for optional
parameters.  Consequently, calling style the three of us agree is C,
I believe.  B is a special case of C without mandatory arguments.


> > before it turns out into yet another ping-pong discussion between Soji 
> > and myself ?
> >
> >> How about use of "shift"?
> > I don't really care about using 'shift', 'pop', 'push' or any other 
> > way to retrieve subroutine parameters, this is mostly an 
> > implementation detail. What matters here is enforcing consistant 
> > subroutines prototypes.
> Same here.

In my experience use of "pop" is very rare, although I have seen
once.  I have no idea on use of "push" (or "unshift").

However, if Guillaume doesn't mind of "implementation detail",
I with to continue using following style:

C-2)

sub foo {
    my $a = shift || "default";
    my $b = shift;
    my %params = @_;
}
foo($a, $b, option => $c);

Though I don't stick to use of "shift", I've also found it often
makes initialization of mandatory args clearer (as example of $a
above).

In addition, this style is bloadly used in code of Sympa.  I can't
find the reason to change it.


Regards,

--- Soji

-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/