in reply to Re: What would you change?
in thread What would you change?

I am a fan of prototypes. I know it is not recommended in Perl Best Practices because of the danger of someone pushing argments into an array and then passing the array.. e.g.

  sub prototyped( $ $ ) {
    print( "Arg 1: " . $_[0] . "\n" );
    print( "Arg 2: " . $_[1] . "\n" );
  }

  my @args = ( "first", "second" );
  prototyped( @args );

[download]
returns the following error:
  Not enough arguments for main::prototyped

[download]

However, as much as the prototype solution is broken for this situation, I'm still a fan of prototypes.

Having prototypes has helped track down a bug in code used in production in a company whereby someone went in and modified the code adding a new parameter to each function. And then a minor bug slipped through whereby a call to one of the functions didn't provide enough arguments.

Prototypes would have caught this in the compilation phase. In fact, by adding prototypes to all the functions we caught another instance whereby a function was being called with the wrong number of parameters..

Replies are listed 'Best First'.
Re^3: What would you change?
by grinder (Bishop) on May 17, 2008 at 12:54 UTC

    When adding a new parameter to each call of a function, have the code behave one way with N args, and a different way with N+1. Ideally, by synthesising a default value for the missing parameter, and then going ahead and doing the same thing.

    There are many ways of working around this sort of codebase evolution. Having the code fail badly because one call was missed is just wrong. Perl is not C.

    As to the other point, yes it's true that prototypes catch things at the compilation phase, but it doesn't deal with passing a text string when a numeric was expected. For that, Params::Validate is a much more robust approach to ensure parameters are sane, especially in a large code base.

    • another intruder with the mooring in the heart of the Perl

[reply]
Re^3: What would you change?
by almut (Canon) on May 17, 2008 at 14:39 UTC

    Although I normally neither use nor need prototypes in Perl, I'd still love to see them being extended in such a way that you could make regular Perl functions behave like Perl builtins in every respect (think of overriding print, system, etc.).  I've come across some discussion along these lines on p5p (e.g. here), but I think things never went beyond just being discussed.

    (This is not my entire Perl 5 wishlist, btw, but the other items are still too vague / not thought-out enough yet, that I would dare to present them to this audience :)

[reply]
[d/l]
[select]
Re^3: What would you change?
by dragonchild (Archbishop) on May 19, 2008 at 01:51 UTC
    vec() is prototyped. This pisses me off.
    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
[reply]
        my $thing = 'a' x 10;
my @params = ( 2, 3 );
vec( $thing, @params ) = 0;

        [download]
        That results with "Not enough arguments for vec()." And, illustrates in brilliant colors the stupidity of compile-time checking in a dynamic language.

        Frankly, if we wanted to have compile-time checks, we should be telling the compiler what we expect to happen. So, for example, if @params should have 2 and only 2 things, we should be able to say that. Then, vec() knows that if @params makes it to him, it's got two things. But, even that sucks because you'd have to assign two things to @params - you wouldn't be be able to build it up using push.

        So, compile-time checks suck.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
[d/l]

In Section Meditations