Named parameters have a sliding value based upon how variable they are -- that is, mandatory or not -- and how many you have. In your case, since some of them may be undef and since you have a number well beyond reason, you'll benefit from using them. However, any function that takes 61 arguments -- heck, that takes more than 6 -- probably indicates poor design. That's like including in the instructions for making coffee 1) be born poor in the Southern Hemisphere; 2) go to school for two years; 3) begin picking beans for Starbucks to support your family; 4 -10) ....; 11) profit!!!; 12) go the store to buy a pound of premium coffee beans .... I would love to see an outline of what in the world this thing is doing with 61 arguments. I'm sure it can be refactored.
As far as the expense of hashtables goes, first compare your emotional pain under the current system with what you envision given named parameters. Next, note that in your sample code you're not actually constructing a hash as a parameter, named or anonymous. Rather, you're building a list that then is used inside the sub to populate a hash. So if you're worried about unnecessarily creating intermediate objects, you should be okay.
In reply to Re: passing subroutine args as a hash: why not?
by djantzen
in thread passing subroutine args as a hash: why not?
by Willard B. Trophy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |