Re^3: How to pass two lists to a sub?

I prefer to use the "shift" function

I think using shift to pull in arguments is occasionally warranted, but it should be avoided most of the time. My reasons are as follows:

It's less maintainable. To add a new argument, you either have to copy and paste the shift line, and modify the variable name, or you have to retype essentially the same thing each time. These are both error-prone processes. Error-prone processes should be avoided whenever possible.
Each shift modifies the @_ array. My concern with this is not about performance (see a related post), but about semantics. Sometimes it makes sense to modify the array, and in those cases I use shift. But usually you are just trying to copy the arguments into more convenient variable names, and that does not necessitate the destruction of the array.

Accessing @_ directly does not have these problems. Using the common construction my ($foo, $bar, $baz) = @_; makes it easy to add new arguments, and it does not mangle @_ as a side-effect. I would be interested to hear your reasons in favor of shift-by-default, because, to me, the reasons against it are pretty convincing.

Comment on Re^3: How to pass two lists to a sub? Download Code

Replies are listed 'Best First'.
Re^4: How to pass two lists to a sub? by archen (Pilgrim) on Nov 05, 2004 at 23:18 UTC
The main reason I use shift over @_ is to easily set up defaults and quickly get some error checking out of the way. Consider: `my $var1 = shift \|\| 'default'; my $var2 = shift \|\| return 0;` [download]	[reply] [d/l]
Re^4: How to pass two lists to a sub? by hmerrill (Friar) on Nov 08, 2004 at 13:31 UTC
I respectfully disagree with both points. I disagree that shift makes code less maintainable. I agree that you are forced to change the code when a parameter is added, but I'm hard-pressed to come up with any situations where adding parameters _shouldn't_ warrant changing the code. If you are changing what is coming in to a subroutine, are you not changing the function of the subroutine??? Being explicit about exactly what parameters a subroutine takes in is just being clear - in my mind that makes the code _more_ maintainable. For what reason would you want to maintain the original @_ array? I can't see any reason that maintaining the original argument array has any advantage over individual arguments created by shift. I don't typically (ever?)change the values of parameters taken into a subroutine anyway (does anyone else?) so maintaining the original parameter list is really no different with shift than it is with assigning variables from @_. Feel free to disagree with me - for now I can't see any merit to your exceptions to using "shift'.	[reply]
Re^5: How to pass two lists to a sub? by revdiablo (Prior) on Nov 08, 2004 at 17:42 UTC
I'm not sure if this discussion still interests you. If not, feel free to ignore this reply. I am not trying to prove you wrong, I just don't want my point of view to be misunderstood. I agree that you are forced to change the code when a parameter is added, but I'm hard-pressed to come up with any situations where adding parameters _shouldn't_ warrant changing the code. It's not the fact that you have to change the code, it's how you have to change the code. Using a series of shift lines, there is a lot more code overhead than using a list assignment from @_. Overhead often causes problems, especially when modifying existing code. When it can be avoided, I think it should. Being explicit about exactly what parameters a subroutine takes in is just being clear How is a list of variable names not explicit? Granted, the shift lines are more spread out, and perhaps more visible. But a list of variables in the first few lines of a subroutine is not exactly obfuscation. I think both are pretty clear. The shift lines may be marginally more clear, but not enough that it matters. For what reason would you want to maintain the original @_ array? I can't see any reason that maintaining the original argument array has any advantage over individual arguments created by shift. As I said before, I tend to look at it from the other point of view: for what reason would you want to destroy the original @_ array? I just get an uneasy feeling clobbering something unnecessarily. So, when there is an alternative way of doing something, and the alternative is better or equal in other ways, then I'll use it. Keep in mind, I am not saying shifting parameters is never warranted. I do it frequently. There are many cases where destroying @_ makes perfect sense, and in those cases, I have no problem whatsoever. It's just in the "default case", when there is no reason to destroy it, I don't. Feel free to disagree with me - for now I can't see any merit to your exceptions to using "shift'. Hopefully you see it as a friendly disagreement. I do not mean to be confrontational, I just do not prefer the shift-by-default method of accessing subroutine arguments. I'm a bit disappointed that you don't see any merit to my reasons. I certainly see merit in yours, I just don't agree that it's the right thing to use most of the time.	[reply]
Re^6: How to pass two lists to a sub? by hmerrill (Friar) on Nov 08, 2004 at 18:57 UTC
Same here, and I didn't think you were being confrontational :) Also not trying to prove you wrong - just trying to understand your views on shift. Your last response helps me better understand your reasoning. It's not the fact that you have to change the code, it's how you have to change the code. Using a series of shift lines, there is a lot more code overhead than using a list assignment from @_. Overhead often causes problems, especially when modifying existing code. When it can be avoided, I think it should. Ok. Correct me if I'm wrong - I think your point here is that Less Code vs. More Code when they both _do_ the same thing is that less code is better. On the face of it I agree with you, but I don't agree when more code makes the code more understandable (I'm not saying that more code in this case is better). In this case I think you're right - functionally, shift vs. @_ are the same, but assigning parameter variables from @_ has the advantage of leaving the argument list intact, and it is less code. I'm not sure either one of those reasons or both is enough to sway me to using @_ but I'll certainly think about from now on instead of just using shift :) How is a list of variable names not explicit? Granted, the shift lines are more spread out, and perhaps more visible. But a list of variables in the first few lines of a subroutine is not exactly obfuscation. I think both are pretty clear. The shift lines may be marginally more clear, but not enough that it matters. Agreed. As I said before, I tend to look at it from the other point of view: for what reason would you want to destroy the original @_ array? I see your point. I didn't really mean that I didn't see any merit - it just took a little more explaining for me to understand your position.	[reply]