Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: Poor Man's Prototyping?

by jlongino (Parson)
on Nov 24, 2001 at 22:25 UTC ( [id://127288]=note: print w/replies, xml ) Need Help??

in reply to Poor Man's Prototyping?

I don't suppose there is any reason why you can't do it that way. My only question is why? It seems like it adds unnecessary code bloat, makes things more difficult to read and is less idiomatic than @_ and shift. But that is just my opinion and I'm sure there are others who will disagree (and they're entitled).

Update: I can see where it is useful in the cases that chromatic describes. But for casual substitution of @_ and shift I'd still have to say that it is unattractive and overkill.


Replies are listed 'Best First'.
Re: Re: Poor Man's Prototyping?
by chromatic (Archbishop) on Nov 25, 2001 at 03:25 UTC
    It's a good technique when you have optional arguments to pass to a sub, or you have more than three or four. Look at the constructor for any of the IO:: modules, for example, or (as has been stated) just about anything in

    Don't overlook the ability to provide default arguments as well. This isn't always appropriate, but there are times when it handily beats @_ and shift.

Re: Re: Poor Man's Prototyping?
by edebill (Scribe) on Nov 25, 2001 at 19:27 UTC

    I'd even nuke the shift. I replace:

    sub dosomething{ my $foo = shift; my $bar = shift;


    sub dosomething{ my ($foo, $bar) = @_;

    That gets all the args and their order right up on the first line of the sub, where it's easier to see. I tend to agree with the Linux kernel CodingStyle document when it says that if you have more than 2-3 args there's probably some re-factoring in order. Cutting and pasting your function calls just seems... icky.

      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.

        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.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://127288]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2024-04-20 01:05 GMT
Find Nodes?
    Voting Booth?

    No recent polls found