Re: use 'local' modifier to hashref element

[kennethk]

Yes, it works.

use strict;
use warnings;
use Data::Dumper;


my $hash_ref = {1 => 2, 3 => 4};
BLOCK: {
    local $hash_ref->{1} = 5;
    print Dumper $hash_ref;
}

print Dumper $hash_ref;

The clearest documentation on this, IMHO, is Temporary Values via local() in perlsub. Essentially, you can localize any hash or array value, which will be restored once you exit the current scope. This trick is frequently used with the %SIG handlers. When you do the localization, you are localizing the element in the hash that the reference points at.

Update: When to Still Use local() is actually the better doc link for this question.

[schetchik]

I forgot to write in my main message. I'm mostly interesting in localization of variables with lixical scope. Because

A local just gives temporary values to global (meaning package) variables. It does not create a local variable ©perldoc

but my variable is not global( or package ) it's just hash reference.

That's why I have some doubts

[kennethk]

local acts on the value, not the variable. Don't think about it as localizing the hash reference, nor even localizing the hash. If you look at the code I've provided, I have no explicit package variables, and I'm localizing a value stored in an anonymous hash.

The reason for your cited line from the documentation is to try to prevent people from thinking that my and local do anything even remotely similar. (That's a little hyperbole, which I can expound upon as necessary).

Update: Code is worth a thousand words.

use strict;
use warnings;
use Data::Dumper;


my $hash_ref = {1 => 2, 3 => 4};
BLOCK: {
    local $hash_ref->{1} = 5;
    $hash_ref->{3} = 6;
    print Dumper $hash_ref;
}

print Dumper $hash_ref;

Note the localized value associated with the key 1 is restored when you exit the block, but the (unlocalized) value associated with the key 3 is not.

[nbtrap]

Interestingly, the code:

#!/usr/bin/perl

use warnings;
use strict;

my %hash;
my @array;

{
    local $hash{foo} = 'bar';
    local @array;
}

complains that you "Can't localize lexical variable @array", but it has no problem localizing $hash{foo}.

Even more interestingly, the code:

#!/usr/bin/perl

use warnings;
use strict;
use Data::Dumper;

my %hash;
our @array;

{
    local $hash{foo} = 'bar';
    local @array;
    print Dumper(\%main::);
}

shows that the localization of the hash slot does _not_ manipulate the symbol table--even without "use strict".

[rovf]

I'm mostly interesting in localization of variables with lixical scope.

As you already point out, local acts on the symbol table of the respective package, i.e. on global variables. In your case, I don't see a way how you can have a single hash element automatically restored at the end of the block.

If this feature is really important to you, did you consider a package global variable declared with "our" (i.e. a lexically scoped global variable) as an alternative? However, I personally would restore the hash entries manually at the end of the block.

[kennethk]

You may want to reconsider what you've said here.

use strict;
use warnings;
use Data::Dumper;


my %hash = (1 => 2, 3 => 4);
BLOCK: {
    local $hash{1} = 5;
    print Dumper \%hash;
}

print Dumper \%hash;

What you've said is true for localizing lexical scalars; however localizing values in lexical arrays and hashes is no problem. See When to Still Use local(), item #3. Sorry if I've misread your intent.

[Anonymous Monk]

Test it. It works. It is more reliable than manually restoring code because you don't have redundant code to mess up on, and because you don't have to worry about exceptions skipping that code. I've been using the trick since Perl 5.005. The ONLY type of scalar that you can't use local on is one defined with my. And that was rejected not because it was hard - it is easy - but because Larry Wall thought that it would confuse people to allow that.