Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 27/02/2014 04:00, IKEDA Soji a écrit :
> > Second, assuming than copying parameters into local variables always
> > brings additional benefits from compilation-time checks is discussable,
> > especially for short functions, ie:
> >
> > sub function {
> >       my (%params) = @_;
> >
> >       return $params{a} . '@' . $params{b};
> > }
> >
> > sub function {
> >       my (%params) = @_;
> >
> >       my $a = $params{a};
> >       my $b = $params{b};
> >
> >       return $a . '@' . $b;
> > }
> >
> > The potential typo issue in the actual code of the function in the
> > second form is actually just displaced in the local variable
> > affectation: no safety gain, with two additional variable copies.
>
> I meant of errors on caller side.  If all parameters of all
> public interfaces would be named:
>
> 1. At first we (implementers) must choose appropriate names;
That's the very reason I prefer it: using meaningful symbol names makes 
code self-explicit

> 2. everyone to use interfaces must know all of these names;
As much as anyone using a positional-paramater based function must know 
correct parameter order to use it correctly

> 3. and they must not use incorrect names.
Same as previous arguement

> By each point above, new loads on programming will be added.
> For example, hadn't you mistyped the name of parameters named by
> yourself, had you?
I had, of course, as everyone else. However, arguing than positional 
argument automatically makes code safer, because you can't use incorrect 
names, is highly subjective.

I believe than making the code more readable for humans also makes it 
easier to review, and fix bugs. And it this regard, named arguments are 
a better option. For instance, a computer will probably not spot the 
error in the following invocations, but a human will probably notice the 
issue with the second one:
Sympa::Tools::Daemon::remove_pid(1337, 'sympa.pl')
Sympa::Tools::Daemon::remove_pid(name => 1337, pid => 'sympa.pl')

And if you test the presence of parameters, as it was the consensus 
earlier, the computer will also notice missing parameters resulting of 
spelling error in parameter names, ie:

sub remove_pid {
    my (%params) = @_;

    my $id   = $params{pid}  || croak "missing pid parameter";
    my $name = $params{name} || croak "missing name parameter";
    ...
}

> You may possiblly say such a loads are small to consider.  I don't
> agree.  Code of Sympa is open to numerous people.  Generally
> speaking, it would be good that unobvious restrictions are reduced.
>
>
> However, if an interface has many optional parameters, named
> parameters may be useful, because programmers may explicitly select
> parameters they want to use.
>
> In conclusion, I proposed that mandatory parameters would be
> positional arguments and optional ones would be named.
I totally disagree here. Mixing parameters style just brings useless 
complexity for me. And I think David also agreed, before you attempted 
to convince us than mixed parameters style is just a subcase of named 
parameter style.

Let's recall the vote between the 3 proposals:
- named parameters style: Guillaume, David
- positional parameters style:
- mixed parameters style: Soji

Marc, Etienne ?

> > Third, the ability to reuse initial parameters list directly is very
> > useful in some circunstances, such as wrapping functions with other
> > functions, ie:
> >
> > sub generic_function {
> >       my (%params) = @_;
> >       ...
> >       return $something;
> > }
> >
> > sub less_generic_function {
> >       return generic_function(@_, foo => 'value');
> > }
> >
> > That's exactly the case of current wwslog() function, for instance, that
> > just wraps do_log() function. I wouldn't call it a bug, and even less
> > enforce a mandatory removal of initial parameters list.
>
> Pass-though @_ seems exceptional case for me.
>
> Moreover, it hurts independency of subroutine calls: On second
> case, if an element of @_ was modified from inside subfunction,
> a variable at outside of main function will be modified.  For
> example:
>
>    sub x { $_[0] = 'red'; }
>
>    $color = 'green';
>    x($color);
>    # Now $color is 'red'.
>
> This is one of reasons why some people insists use of "shift".
> If @_ is broken at first in the subroutine, references to variable
> on caller-side are broken (See perlfunc(1)).
I'd rather argue than a function modifying its parameters directly is 
highly discussable at first place. And rather than optimising code for 
workarounding unexpected side-effects, we should rather fix borken code 
directly.
--
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