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

[tilly]

This is something I would call a matter of personal taste. I talked about it at Silly code reviews and shift, and as I said there, it certainly is common to find shift used in argument processing in core modules, CPAN, etc. I have personally tried it both ways.

My current opinion is that whether or not using shift for processing or assigning in one line is better is dependent on the rest of your coding style. As my style has changed it has gone from being definitely better to shift to (currently) being essentially indifferent.

Furthermore on named arguments, I agree that long argument lists maintained by argument order are a bad idea. But I do not agree that the Linux kernel CodingStyle applies directly to Perl. In particular in Perl it is often very good style to develop list-based functions which may easily have 10 or 1000 arguments. And often you want to provide various kinds of optional default behaviour. In which case, as suggested in the root node, I find it best to provide a named parameter style with reasonable defaults where appropriate. 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.

Try it. It may take some time to be able to take good advantage of the flexibility offered. But I think that knowing how and when to do that is a good tool to put in your toolbox for languages that give you a way to do it.

[edebill]

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.

[tilly]

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.