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.