Perl provides a simple mechanism for specifying subroutine argument types called prototypes. However, prototypes are problematic in many ways. First, prototypes do not affect functions defined using the & character. Furthermore, according to the perlfunc manpage [Wall 2011]:
Method calls are not influenced by prototypes either, because the function to be called is indeterminate at compile time, since the exact code called depends on inheritance.
Prototypes appear to indicate the number and types of arguments that a function takes. For instance, this function appears to require two arguments, the first being a scalar, and the second being a list:
| Code Block | ||||
|---|---|---|---|---|
| ||||
sub function ($@) {
# ... function body ...
} |
However, prototypes are problematic in many ways. The biggest problem is that prototypes are Prototypes are also not enforced by Perl's parser. That is, prototypes do not cause Perl to emit any warnings if a prototyped subroutine is invoked with arguments that violate the prototype.. Perl does not issue any warnings of prototype violations, even if the the -w switch switch is used. Finally, prototypes also can
Prototypes suffer from several other problems, too. They can change function behavior, by forcing scalar context when evaluating arguments that might not be scalars, or by forcing list context when evaluating arguments that might not be lists. Prototypes do not affect functions defined using the & character. Finally, according to the perlfunc manpage [Wall 2011]:
Method calls are not influenced by prototypes either, because the function to be called is indeterminate at compile time, since the exact code called depends on inheritance.
Because of these problems, subroutine prototypes must not be used when defining subroutines.
Noncompliant Code Example
...