in reply to Re: Declaring Subroutines (predeclare, catch errs at compiletime?)
in thread Declaring Subroutines

Unfortunately, you're confused. But it's a mistake that many people make. I myself was confused until I read this useful article on Prototypes in Perl.

Basically, prototypes are not for catching errors at compile time. Rather, they're for changing the precedence of the subroutine calls.

Normally (when not using parentheses or pototypes), subroutine calls act as list operators, meaning the slurp up everything after them. For example:

print my_sub 1, "\n"; # Actually means: print my_sub(1, "\n");

Prototypes allow you to change this behaviour so that the subroutine call only slurps up as many values as it needs (unless, of course, you explicitly use parentheses).

The article does a better job of explaining it but I hope that helps at least some. :-)

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.

  • Comment on (bbfu) (prototype misconception) Re(2): Declaring Subroutines (predeclare, catch errs at compiletime?)
  • Download Code

Replies are listed 'Best First'.
Re: (bbfu) (prototype misconception) Re(2): Declaring Subroutines (predeclare, catch errs at compiletime?)
by hdp (Beadle) on Apr 25, 2001 at 05:58 UTC
    "Basically, prototypes are not for catching errors at compile time. Rather, they're for changing the precedence of the subroutine calls."
    % perl -le 'sub f ($) { print @_ } f(1, 2)' Too many arguments for main::f at -e line 1, at end of line Execution of -e aborted due to compilation errors. % perl -le 'sub f ($) { print @_ } f()' Not enough arguments for main::f at -e line 1, at end of line Execution of -e aborted due to compilation errors.

    Prototypes have been catching errors of this sort since 5.002.

    hdp.

      In my experience prototypes cause more errors than they solve, plus accidental interpretation of an array as a scalar is a far more confusing error than getting the number of arguments wrong.

      Besides which, when you have to teach someone Perl it is far easier to not use prototypes (and tell them that not using them is part of a coding standard if they do discover them) than it is to explain what they are and (if they are coming from C) explain why they don't really do what you might expect from something called a prototype.

      Well, ok. I suppose I should've said that, while prototypes will catch some errors at compile time, that is not what they were really intended for. Plus, they can (and will) introduce other, less obvious errors at run time. The article explains it much better than I could; if you have not already read it, I suggest you do.

      Regardless, my point was that you should be sure that you understand what prototypes really do before using them and that some simple "error checking" is not a good reason to use them (even if you do understand them).

      Prototypes can be useful in a few (very few) situations. Unfortunately, their use, especially for the wrong reasons, can also be dangerous.

      bbfu
      Seasons don't fear The Reaper.
      Nor do the wind, the sun, and the rain.
      We can be like they are.