It is easy for two hashes to be the same but have different scalar sizes.

Regarding prototypes, I'll take a look at the link. But my code expects two hashrefs, not hashes.

Cheers,
Tom

Ah, my misreading. Sorry.

The code expects two hashrefs. While a prototype of \%\% might arguably be better, I don't see an advantage to not having any prototype in this case. Moreover, I do see a disadvantage in that if somebody mistakenly passes something other than the required two and only two arguments, the error won't be caught at compile time.

Thanks for any enlightenment you can share.

I say that you are better off avoiding prototypes in general. Any individual use is a small deal, it is when you put them together that you get the problem.

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.