Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Re (tilly) 3: Poor Man's Prototyping?

by edebill (Scribe)
on Nov 26, 2001 at 20:33 UTC ( [id://127564] : note . print w/replies, xml ) Need Help??


in reply to Re (tilly) 3: Poor Man's Prototyping?
in thread Poor Man's Prototyping?

Typically the calls will either wind up (at least in my code) being a pass-through hash, or else I will just use a few of the possible options in any particular code.

In which case you're really only passing a single arg - the hash ref :-)

I still think it's better to pass  foo($bar, $baz, \@quux) and then operate on the array ref than  foo($bar, $baz, @quux) and shift through the last args. If nothing else it'll be faster to call by reference.

But really, my complaint is for things like:   $newhash = session::create_hash($sha, $userid, $come_from, $go_to, $sessionid, $time, $hash_secret); which could very well benefit from not having to pass in things which are almost always constant ($sha and $hash_secret), and which could be turned into an object and reduced to

$newhash = $session->create_hash($come_from, $go_to, $time);

which is much more readable.

and yes, $time would be an optional argument -

sub create_hash{ my ($self, $from, $to, $time) = @_; unless($time){ $time = time(); }

variable argument lists - where all the args are basically the same thing to operate on are no problem. It's when you have lots of args which are all required (and different) that the sub gets really hard to use. Trying to remember 12 arguments, all of which are required just isn't going to work. Even if you do named arguments. On the other hand, I do agree that named args might be useful for optional args.

Replies are listed 'Best First'.
Re (tilly) 5: Poor Man's Prototyping?
by tilly (Archbishop) on Nov 26, 2001 at 20:56 UTC
    I said I was passing through a hash, and you assumed that I was passing through a reference to a hash?

    Bad assumption.

    I pass through a list of key/value pairs, and construct the hash inside of the function. Why? So that I can then proceed to do destructive processing on said hash without bothering my caller. Furthermore it allows the easy setting of a few optional defaults in a wrapper function:

    sub some_wrapper { # Do some wrapper type stuff here. real_function( key1 => $default1, key2 => $default2, @_ ); }
    But you cry about efficiency! I respond, So what? If my code is performance critical, I will worry about performance. Usually it isn't, and I will worry about my sanity first, second, and fourth. (Third is other people's sanity or lack thereof.)

    As for your complaint, true. In languages where arguments are positionally placed, more than 2-3 arguments gets cumbersome. I find that with named arguments the average person's threshold goes up. 5-6 arguments is not problematic. Our name association goes father than the memorization of orders of arguments, and the type of error changes from messing up argument order (hard to catch) to typos (which I place automated checks for). And people who can consult documentation are extremely tolerant of large numbers of possible optional arguments, just so long as they are pretty much independent.