Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 25/02/2014 13:21, IKEDA Soji a écrit :
> 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.
No, that's not.

The main point of named parameters is to get rid of parameters ordering 
issues first, undescribed parmeters second. Mixing both styles just 
brings disadvantages of both with added useless complexity.

[..]
> 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).
Then you'd better argue about the intent (initialisation of default 
values), rather than the syntax. Because the exact syntax doesn't matters:

my $a = $params{a} || 'default';

my (%params) = (
    a => 'default',
    @_
);

etc...

> In addition, this style is bloadly used in code of Sympa.  I can't
> find the reason to change it.
Consistency is enough reason for me, whatever the exact convention used. 
Provided we don't need yet another endless thread to find a consensus.
--
Guillaume Rousse
INRIA, Direction des systèmes d'information
Domaine de Voluceau
Rocquencourt - BP 105
78153 Le Chesnay
Tel: 01 39 63 58 31

Attachment: smime.p7s
Description: Signature cryptographique S/MIME