Is there a difference between Perl's shift versus assignment from @_ for subroutine parameters?

Question

Let us ignore for a moment Damian Conway\'s best practice of no more than three positional parameters for any given subroutine.

Is there any difference between the t

Answer 1

I prefer to unpack @_ as a list (your second example). Though, like everything in Perl, there are instances where using shift can be useful. For example passthru methods that are intended to be overridden in a base class but you want to make sure that things still work if they are not overridden.

package My::Base;
use Moose;
sub override_me { shift; return @_; }

Answer 2

The best way, IMHO, is a slight mixture of the two, as in the new function in a module:

our $Class;    
sub new {
    my $Class = shift;
    my %opts = @_;
    my $self = \%opts;
    # validate %opts for correctness
    ...
    bless $self, $Class;
}

Then, all calling arguments to the constructor are passed as a hash, which makes the code much more readable than just a list of parameters.

Plus, like brian said, the @_ variable is unmodified, which can be useful in unusual cases.

Answer 3

I would imagine the shift example is slower than using @_ because it's 6 function calls instead of 1. Whether or not it's noticeable or even measurable is a different question. Throw each in a loop of 10k iterations and time them.

As for aesthetics, I prefer the @_ method. It seems like it would be too easy to mess up the order of the variables using the shift method with an accidental cut and paste. Also, I've seen many people do something like this:

sub do_something {
   my $foo = shift;
   $foo .= ".1";

   my $baz = shift;
   $baz .= ".bak";

   my $bar = shift;
   $bar .= ".a";
}

This, IMHO, is very nasty and could easily lead to errors, e.g. if you cut the baz block and paste it under the bar block. I'm all for defining variables near where they're used, but I think defining the passed in variables at the top of the function takes precedence.

Answer 4

I prefer using

sub do_something_fantastical {
    my ( $foo, $bar, $baz, $qux, $quux, $corge ) = @_;
}

Because it is more readable. When this code is not called to much often it is worth way. In very rare cases you want make function called often and than use @_ directly. It is effective only for very short functions and you must be sure that this function will not evolve in future (Write once function). I this case I benchmarked in 5.8.8 that for single parameter is shift faster than $_[0] but for two parameters using $_[0] and $_[1] is faster than shift, shift.

sub fast1 { shift->call(@_) }

sub fast2 { $_[0]->call("a", $_[1]) }

But back to your question. I also prefer @_ assignment in one row over shifts for many parameters in this way

sub do_something_fantastical2 {
    my ( $foo, $bar, $baz, @rest ) = @_;
    ...
}

When Suspect @rest will not be to much big. In other case

sub raise {
    my $inc = shift;
    map {$_ + $inc} @_;
}

sub moreSpecial {
    my ($inc, $power) = (shift(), shift());
    map {($_ + $inc) ** $power} @_;
}

sub quadratic {
    my ($a, $b, $c) = splice @_, 0, 3;
    map {$a*$_*$_ + $b*$_ + $c} @_;
}

In rarely cases I need tail call optimization (by hand of course) then I must work directly with @_, than for short function is worth.

sub _switch    #(type, treeNode, transform[, params, ...])
{
    my $type = shift;
    my ( $treeNode, $transform ) = @_;
    unless ( defined $type ) {
        require Data::Dumper;
        die "Broken node: " . Data::Dumper->Dump( $treeNode, ['treeNode'] );
    }
    goto &{ $transform->{$type} }   if exists $transform->{$type};
    goto &{ $transform->{unknown} } if exists $transform->{unknown};
    die "Unknown type $type";
}

sub switchExTree    #(treeNode, transform[, params, ...])
{
    my $treeNode = $_[0];
    unshift @_, $treeNode->{type};    # set type
    goto &_switch;                    # tail call
}

sub switchCompact                     #(treeNode, transform[, params, ...])
{
    my $treeNode = $_[0];
    unshift @_, (%$treeNode)[0];      # set type given as first key
    goto &_switch;                    # tail call
}

sub ExTreeToCompact {
    my $tree = shift;
    return switchExTree( $tree, \%transformExTree2Compact );
}

sub CompactToExTree {
    my $tree = shift;
    return switchCompact( $tree, \%transformCompact2ExTree );
}

Where %transformExTree2Compact and %transformCompact2ExTree are hashes with type in key and code ref in value which can tail call switchExTree or switchCompact it selfs. But this approach is rarely really need and must keep less worth college's fingers off.

In conclusion, readability and maintainability is must especially in perl and assignment of @_ in one row is better. If you want set defaults you can do it just after it.

Answer 5

I suspect if you're doing the (rough) equivalent of:

push @bar, shift @_ for (1 :: $big_number);

Then you're doing something wrong. I amost always use the my ($foo, $bar) = @_; form cos I've shot myself in the foot using the latter a few too many times ...

Answer 6

I prefer

sub factorial{
  my($n) = @_;

  ...

}

For the simple reason that Komodo will then be able to tell me what the arguments are, when I go to use it.