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

[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;
    # ...
}