I disagree. I prefer passing named arguments as a hash reference:

    sub Open {
        my( $file, $opts )= @_;
        foreach $key (  %$opts  ) {
            # ...
        }
    }

    Open( "file", { ReadOnly=>1, Retries=>2 } );
[download]

• It leaves lots of room for flexability in the API. For example, if my routine requires a 'file' parameter, then I don't see much point in requiring you to type File => when I can do things as above. You can even have optional parameters:

      sub Open {
          my $opts= UNIVERSAL::isa( $_[-1], "HASH" )
              ? pop(@_) : {};
          my( $file, $mode, $mask )= @_;
          # ...
      }
  
      Open( "file" );
      Open( "file", { Exclusive=> 1 } );
      Open( "file", "w", 0666, { Locked=>1 } );
  [download]

• The "Odd number of elements in hash assignment" warning automatically gets thrown at the calling code where it belongs
• It provides a visual cue that named arguments are being used
• It stops you from getting tricky and doing:     Create( Name=>"This", Users=>'fred','bob','joe' ); which you will regret later. Instead you are forced to:     Create( Name=>"This", Users=>['fred','bob','joe'] );

sub add_person {
  my %person = ();
  @person{qw(firstname lastname addr1 addr2 city state zip)} = @_;
  ...
}
[download]

vs.

sub add_person {
  my %person = ();
  $person{firstname} = shift;
  $person{lastname} = shift;
  $person{addr1} = shift;
  $person{addr2} = shift;
  $person{city} = shift;
  $person{state} = shift;
  $person{zip} = shift;
  ...
}
[download]

The first one just seems a lot cleaner to me. (Of course, in practice you might have the list of field names in a predefined array that you could loop through, but you get the idea.)

--Kevin

Unfortunately not. routine1 makes the assignment without modifying @_, whereas routine2 consumes elements of @_. Add something like return $_[0]; to each of the above and in general you will get different results...

        $perlmonks{seattlejohn} = 'John Clyman';