Here is an answer to your rhetorical question.
The problem with using prototypes is that you are making
assumptions for the person using your code about exactly
how they are going to use it. Prototypes have many silent,
nasty and unexpected side-effects. For instance perhaps
the person using your code wants to have the parameters
in an array. Oops, they need an array slice, but may not
understand why. Perhaps they want to dynamically decide
what goes into your second argument and so use a trinary
operator. Oops, not allowed by the prototype, you need to
use temporaries. Perhaps they are returning the output of
a function to decide what your parameters should be. Oops,
not allowed by the prototype, you need a temporary array
and then a slice. Either that or multiple temporary
scalars.
None of these are very intuitive bugs for me to figure
out. Nor when I have to bring someone up to speed on Perl
do I want to waste energy on explaining the whys and
wherefores of prototype-caused errors. It is simpler to
just pretend that they don't exist.
So using them, even when the usage is clear, is problematic
at best. It is, in fact, very easy to achieve the same
basic effect without the side-effects by a run-time check
inside of the function. And the same approach will also
work inside of method calls. It works no matter what order
in your file the functions are declared in. Consistency and
flexibility are
Good. Making assumptions for your caller is Bad.
But there are more reasons not to use prototypes for
checking. When you use prototypes, you are forcing
yourself into a single positional style of programming.
You have put on a blinker where you are disregarding the
possibilities of list-based constructs, or the use of
named parameter processing. But I find that using
positional logic is inherently buggy (people make mistakes
with what order parameters go in), and I find tremendous
flexiblity in using dynamic list-based approaches where
applicable.
So I find the win from prototypes to come with problems at
best, and at worst trying to get it limits the kinds of
solutions that can be tried. In other words they get me
coming and going.
All of this is why when this topic came up what I said in
chatter was, Given the choice, I would refuse to work
with a programmer who understood how Perl's prototypes work,
understood the gotchas, and used them liberally anyways.
It would be a cognitive mismatch. What I mean by that
is that working with that code would be a constant source
of frustration for me. And I simply would not want to
do it. |