The problem is that your APIs become more complex, and more potentially surprising to someone else (who might be you, later). For instance perhaps sometimes in this situation you use $$ as a prototype, and in others you use \%\%. When you're coding, are you going to remember which you're in the habit of using? Maybe not. So sure, you know that you need 2 arguments, but to be sure that you aren't messing up you need to actually run the code, to be sure that you didn't write %foo when you needed to write \%foo, so it got coerced wrong. And then you run across code where someone passes in %foo, but it is going into a list of key/value pairs and you don't realize that. Or vice versa code where you thought it was supposed to do that but instead it got coerced. Or even code where you meant it to be coerced but the function got defined later than you thought and so no coercion took place.
And when similar functions have different prototypes, then you get into the issue given at printf vs. sprintf. That can cause confusion in the unsuspecting for a while.
And then we get the learning curve of things that do not scale well as you get to more sophisticated programming techniques. For instance if you go to OO programming, all of the effort that you spend thinking about prototypes goes out the window since they get ignored. But you or your maintainance programmer might not realize that, and can creatively go wrong for a while before finding it out. Likewise if you start playing with closures, wrapping functions, etc, you'll run into the situation that you cannot easily wrap a generic function without worrying about prototype issues.
All little errors. All easy to solve individually. But a constant annoyance that doesn't go away.
The alternative is to not use prototypes at all. Then you practice using a consistent argument passing style. The compile-time check is not a big deal - you do test code, don't you? You can then explore the joys of functions that accept arbitrary lists (I like passing in a hash). You get to use the same style for both functions and methods. And there is less typing.
Perhaps you find this less than convincing. But go through previous threads on the topic and see how many competent people have come to the same conclusion that I have. There is a reason for that. Perl's version of prototypes do not buy you very much, and in the long run they impose a much larger cost than you realize.
In reply to Re^4: Multiple loop variable in foreach statement
by tilly
in thread Multiple loop variable in foreach statement
by tc1364
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |