"That depends."
With a hashref you pass into your subroutine an anonymous hash of name/value pairs, which allows for named parameters, unordered parameter lists, facilitates optional parameters, extendability, and so on.
But it can be a little unwieldy. There is something succinct in "split /:/, $string, 3;" that is lost if it becomes:
split( {
pattern => qr/:/,
input => $string,
giveme => 3
} );
In Perl Best Practices the assertion is that when the parameter list grows to four or more it's time to consider named params. The book doesn't attempt to define the Ten Commandments though. Mostly it's "A lot of good ideas unless you have a good argument to the contrary." I can say it's a rare occasion when I'm able to use a function that has named parameters without first looking them up in the function's documentation again. I don't often have to look up split, and when I do it's to clarify a less common use.
Do remember that named parameter lists via hashes aren't checked at compile-time by strict. So in a general sense, while a hash is very convenient, it doesn't afford some of the protections of first class variables. On the other hand, if ever you're tempted to manipulate variable names programatically, it's probably time to revert to using a hash in the first place.
|