In the original code I used $_[0] and $_[1], I changed that and gave the vars names simply to make it clearer to the OP.

Why (shift,shift)? Why not? It makes it clear that I am only going to consider using 2 parameters. Admittely that can be derived from the left-hand side of the expression, but what is wrong with shift? The docs don't indicate that it is depreciated or anything.

It's not deprecated, in fact, it's very useful. But just because you can use a screwdriver to stir paint doesn't mean you should (JBYCDMYS, the complement to TMTOWTDI). The thing that cheeses me off about shift is that it actually modifies @_. Not that I care in most cases, but it seems like wasted effort, and programs are supposed to be efficient.

I find a few cases where shift is handy, though, such as in these highly simplified examples:

sub new
{
    my $class = shift;
    my $self  = bless ({ @_ }, $class); # Hash-style params

    return $self;
}

sub fooge_default
{
     my $self = shift;

     $self->fooge(@_);  # Blind parameter passing
}
[download]

In most cases, though, you can just do direct assignment, mapping your params to @_ in a single declaration. If you have some sort of sick monstrosity that takes so many paramters you have to split up the declaration on to two lines, maybe you should re-think your interface. Once you're past six arguments, things get hard to parse.

As an example where shift is dangerous, consider this:

sub fooge
{
     my ($foo, $bar) = (shift, shift);

     die "fooge() needs two arguments\n" unless (defined($bar));

     # ...
}
[download]

What's wrong with this? What if undef was a valid parameter? You've destroyed the evidence, so to speak. I'd try to use this instead:

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

     die "fooge() needs two arguments\n" unless (@_ == 2);

     # ...
}
[download]

This version distinguishes between undef and not provided.

Thanks. This and Shift versus Sanity are very interesting. I'm still learning all the why's and wherefor's of perl syntax and semantics. I probably will be for some time to come. I will just about have mastered it, and Perl6 will hit the streets! Hopefully, enough of it will carry over to not invalidate the exercise.

A couple of questions arising:

Wouldn't this

sub fooge_default
{
  my $self = shift;

  $self->fooge(@_);  # Blind parameter passing
}
[download]

be better done as this?

sub fooge_default
{
  my $self = shift;

  goto &$self->fooge;  # Not entirely sure of the syntax
}
[download]

vis

The goto-&NAME form is highly magical, and substitutes a call to the named subroutine for the currently running subroutine. This is used by AUTOLOAD() subroutines that wish to load another subroutine and then pretend that the other subroutine had been called in the first place (except that any modifications to @_ in the current subroutine are propagated to the other subroutine.) After the goto, not even caller() will be able to tell that this routine was called first.

Also, I realise that finding good examples is always a problem, but your example of where shift is dangerous isn't the fault of shift but of the logic of the test.

Using the correct test in the right place make it irrelavent which method is used to access the args I think?

sub fooge
{
  die "fooge() needs two arguments\n" unless (@_ ==2);
  my ($foo, $bar) = (shift, shift); # or @_ are equally safe.

  # ...
}
[download]

---

Well It's better than the Abottoire, but Yorkshire!