in reply to Your named arguments

I'd do:
sub convert { my %arg = @_; my ($from, $to, $thing) = @arg{qw /from to thing/}; ... }
I don't enforce policies of "even if you want to pass in an argument with an undefined value, you must specify it" on my callers. I'm a Perl programmer, so my programs are programmer friendly. Absence of named parameters are fine. I don't balk at extra arguments either - this can be very useful, as wrappers can just call the function with whatever @_ they were called with.

On the other hand, I might work with defaults. Then I'd write it as:

sub convert { my %arg = @_; my $from = exist $arg{from} ? $arg{from} : 'default'; my $to = exist $arg{to} ? $arg{to} : 'default'; my $thing = exist $arg{thing} ? $arg{thing} : 'default'; ... }
Or:
sub convert { my %arg = (from => 'default', to => 'default', thing => 'default', @_); my ($from, $to, $thing) = @arg{qw /from to thing/}; ... }
Or when passing in a false value doesn't make sense, I'd make it that any false value means 'default':
sub convert { my %arg = @_; my $from = $arg{from} || 'default'; my $to = $arg{to} || 'default'; my $thing = $arg{thing} || 'default'; ... }
And when I want to do something fancy, I use Getopt::Long:
sub convert { local @ARGV = @_; GetOptions ('from:s' => \my $from, 'to:s' => \my $to, 'thing:s' => \my $thing); ... }
Perl --((8:>*

Replies are listed 'Best First'.
Re^2: Your named arguments
by creamygoodness (Curate) on Nov 08, 2005 at 19:06 UTC
    There's more than one way to be friendly. :)
    I don't balk at extra arguments either - this can be very useful, as wrappers can just call the function with whatever @_ they were called with.

    The downside of allowing extra args is of course the classic misspelled_lable => 'uh-oh' problem. If such an error isn't caught right away, that can result in some very unfriendly bugs, depending. Do you perform any extra verification to defend against that class of problem?

    Unchecked labels really get ugly if there are default values...

    --
    Marvin Humphrey
    Rectangular Research ― http://www.rectangular.com
      The downside of allowing extra args is of course the classic misspelled_lable => 'uh-oh' problem. If such an error isn't caught right away, that can result in some very unfriendly bugs, depending. Do you perform any extra verification to defend against that class of problem?

      One of the many reasons I love my test suite :-)