Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Use method/function signatures with Perl

by demerphq (Chancellor)
on Dec 06, 2004 at 17:17 UTC ( #412702=note: print w/ replies, xml ) Need Help??


in reply to Use method/function signatures with Perl

IMO stuff like this quickly leads to a cognitive mismatch between their author and the bulk of the perl community. For instance passing more args to a subroutine than it needs should IMO not be viewed as a bug. Its behaviour that many a perl programmer would consider completely normal.

I think people tend to make a big deal out of parameter passing in Perl when really they should remember the old dictum: "programs should be as tolerant as possible in what they accept and strict as possible in what they emit." Id say that applies equally well to subroutines.

Anyway, im not trying to say that your module cant be useful, im sure it will be. But people using it should be reminded that the programs they produce using it wont behave as many experienced perl programmers would expect.

---
demerphq


Comment on Re: Use method/function signatures with Perl
Re^2: Use method/function signatures with Perl
by kscaldef (Pilgrim) on Dec 06, 2004 at 18:18 UTC
    I'd wager that at least 95% of the time, passing more arguments into a subroutine than it expects is a bug.
      I'd take that wager. 95% of the time, passing more arguments into a subroutine than it expects is a sign of forwards- (and sometimes backwards- ) compatability. Other times, it's a sign of API compatability. For example, I've got a templating module that works with more than one rendering engine. There's a given function that both engines support. But, one takes (and handles) a foo parameter and the other doesn't. If I cannot pass the foo parameter in (to be silently ignored if necessary), that's a sign of bad assumptions.

      Be liberal in what you accept and strict in what you emit.

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

        If I cannot pass the foo parameter in (to be silently ignored if necessary), that's a sign of bad assumptions.

        Your assumption that subroutines silently ignore unknown arguments is the bad assumption. Nothing says this is the rule.

        If it's for forwards- or backwards-compatibility then it's not unknown extra arguments. They're there for a reason and the module author is aware of this. Future problems won't arise for you adding those arguments. For my issues with this, see Re^2: Use method/function signatures with Perl.

        As for dispatches (like your example with rendering engines), you can take care of this with very little code changes. In your dispatch table (if you have one -- otherwise create one) add which parameters that should be passed (or which shouldn't be passsed, or whichever way suits your problem) and then pass just those parameters. This is trivial to implement for someone like you. For example, a simple draft to illustrate my solution code-wise can look like

        sub foo { print "foo: @_\n" } sub bar { print "bar: @_\n" } sub safe_dispatch { my ($dispatch, $name, $params) = @_; my ($code, @keys) = @{$dispatch->{$name}}; my @params = map { $_ => $params->{$_} } grep { exists $params->{$_} } @keys; return $code->(@params); } my %dispatch = ( foo => [ \&foo, qw/ foo common / ], bar => [ \&bar, qw/ bar common / ], ); my %params = ( foo => 1, bar => 1, common => 1, ); safe_dispatch(\%dispatch, $_, \%params) for qw/ foo bar /; __END__ foo: foo 1 common 1 bar: bar 1 common 1
        All I've changed from a trivial dispatch is added parameter names in the dispatch table, and use a subroutine instead of $dispatch{$name}->(%params) which typically would be used.

        This approach could easily be tweaked for most other situations and similar problems. I admit there might be cases where this could be cumbersome but for typical use I think it's trivial to get around your problem.

        A little code with a great benefit, the way I see it. (See Re^2: Use method/function signatures with Perl for the benefit.)

        ihb

        See perltoc if you don't know which perldoc to read!
        Read argumentation in its context!

        Perhaps the codebases we work with are quite different, but almost every case I've encountered of people passing the "wrong" number of arguments arose because someone changed the signature of some subroutine and neglected to hunt down every use of it.

        Of course, one response to that is "don't do that", which is certainly valid to some extent. However, with a sufficiently large codebase, and a sufficiently large number of developers with mixed skills and experience, and a language like Perl where tracking down all uses can be challenging to the best of us, there may be something to be said for paranoia.

Re^2: Use method/function signatures with Perl
by ihb (Deacon) on Dec 08, 2004 at 15:22 UTC

    For instance passing more args to a subroutine than it needs should IMO not be viewed as a bug. Its behaviour that many a perl programmer would consider completely normal.

    We've touched this discussion before (Re: Re: Re: Context aware functions - best practices?). I do not agree. There is no concensus on what will happen with the extra arguments. I'm a firm believer of that documentation is what decides what should be considered a bug or not. If the documentation says a subroutine takes three arguments then I read that as the subroutine should be given three arguments. I don't read it as the subroutine should be given minimum three arguments.

    If everyone would live by "it's OK to pass too many arguments" then there would be a lot of unnecessary incompatible updates (i.e. when the module author adds an argument to the subroutine interface). If everyone would live by "it's not OK to pass too many arguments" then module authors wouldn't have to worry about extending the subroutine interfaces and the number of incompatible updates would be reduced.

    Assuming that passing too many arguments is silently ignored is to assume things about the implementation, and assuming things about the implementation is by general concensus evil.

    Just because it works now doesn't mean it'll work tomorrow--unless documented to do so.

    ihb

    See perltoc if you don't know which perldoc to read!
    Read argumentation in its context!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://412702]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (11)
As of 2014-12-22 20:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (128 votes), past polls