I respectfully disagree.
Named parameters means I don't have to pass a string of undefs because one particular call doesn't use those parameters. APIs using positional parameters have a way of requiring difficult upgrade path.
It's also self-documenting -- instead of a list of variables, each variable is named, which can only help the future software forensic expert.
Many years ago, I wrote a User Interface program in C, and one of the things that I used was lots of parameter passing, knowing enough that global variables were not the answer. Eventually, I had a couple of routines that required a dozen or so parameters, and as the code matured into a lovely congealed mass of spaghetti, I began to dread getting in there to fiddle with calls to that code, precisely because I had to add 'just one more' parameter at the end.
The alternative could have been to pass in a pointer to a struct, which is more or less a hashref, but I wasn't secure enough in my abilities to do that. Too bad, because it would have been the right thing to do, just as using a hashref is the right thing to do.
In reply to Re^5: When every microsecond counts: Parsing subroutine parameters
by talexb
in thread When every microsecond counts: Parsing subroutine parameters
by snowhare
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |