Re: Benifits of using hash rather than number of variables?

[DrHyde]

The three big advantages of passing hashes / hashrefs to your subroutines are:

1. you have named parameters inside the subroutine, and you don't have to remember the order of arguments outside the subroutine;
2. much easier to handle optional arguments, and to calculate which arguments to pass at runtime;
3. easy to build up that hash a little bit at a time;

The big disadvantage of using hashes is that you lose some strictness checking. use strict will usually tell you if you mis-type a variable name, but it can't tell you if you mis-type a hash key - instead, if you mis-type a key name when reading the hash, it'll just auto-vivify. This sort of bug can be a real pain in the arse to track down.

Thankfully, there's a solution to this problem on the CPAN. Tie::Hash::Vivify is meant to let you provide "a hash where if you read a key that doesn't exist, it will call a code reference to fill that slot with a value", but it can of course be used thus:

use Tie::Hash::Vivify;
use Carp qw(confess);
use Data::Dumper;
...
my $hashref = Tie::Hash::Vivify->new(sub {
  confess("No auto-vivifying!\n".Dumper(\@_))
});

[duelafn]

See also Hash::Util which is in perl core since 5.8.0

use Hash::Util qw( lock_keys );
my %hash = (foo => 42, bar => 23);
lock_keys(%hash);
say $hash{bae};   # Boom! "Attempt to access disallowed key 'bae' in a
+ restricted hash..."

[JavaFan]

That doesn't really work for named parameters, specially not if some parameters are optional. Unless you're going to do something unwieldy like:

sub whatever {
    unless (@_) {
        my %params = (key1 => undef,
                      key2 => undef,
                      key3 => undef,);
        lock_keys %params;
        return \%params;
    }
    my %params = %{+shift};
    ... sub body using named parameters ...
}

my $whatever_params = whatever();
$whatever_params->{key1} = $value1;
$whatever_params->{key2} = $value2;
$whatever_params->{key3} = $value3;
whatever $whatever_params;

[duelafn]

It will work fine for sub parameters. You can provide a list of keys as a second parameter to lock_keys:

sub whatever {
    my %params = @_;
    lock_keys %params, qw/ key1 key2 key3 /;
    say "Got key1" if $params{key1};    # ok
    say "Got key2" if $params{key2};    # ok
    say "Got key3" if $params{keye};    # Oops - BOOM!
}

whatever key2 => $value2;
whatever keyq => $value1; # Hash has key 'keyq' which is not in the ne
+w key set

For example, I use the following for parsing command-line options in my scripts:

use Getopt::Long qw/:config bundling/;
use Hash::Util qw/ lock_keys /;

our %OPT;
my @OPT_SPEC = qw/ help|h version noact|no-act|dry-run DEBUG output|o=
+s /;
GetOptions \%OPT, @OPT_SPEC or ($OPT{help} = 1);
lock_keys(%OPT, map /^(\w+)/, @OPT_SPEC);

Update 2: A diligent Anonymous monk actually tested this code (actually executing proposed code - what a concept) and pointed out that the initial lock_keys suggestion is sufficient. Updated the comments in the code above to reflect this.

Update: Add example where lock_keys is not quite sufficient... One could solve this in a couple ways without changing how whatever is called: Anonymous monk make all this unnecessary

# Option 1: use Params::Validate

# Option 2:
sub whatever {
    my @param_keys = qw/ key1 key2 key3 /;
    my %params = @_;

    $params{$_} //= undef for @param_keys;
    die "Invalid usage" if @param_keys != (keys %params);

    lock_keys %params;
    # ...
}

# Option 3:
sub whatever {
    my %expected_params = map +($_,1), qw/ key1 key2 key3 /;
    my %params = @_;

    for (keys %params) {
        die "whatever: Unexpected named parameter $_" unless exists $e
+xpected_params{$_};
    }

    lock_keys %params, keys %expected_params;
    # ...
}