Re^2: local variable syntax

In summary, you basically never want to use local.

local is widely misunderstood. The best evidence of this is the frequency of statements like "never use local."

It's more accurate and useful to say that local operates on all variables... except lexical (my) variables. It isn't just for localizing values of whatever package globals your program may have, it is essential for the special globals like $_ and @ARGV.
Furthermore — and this useful fact is often missed — it can localize values in variable spaces which are automatically allocated by the interpreter — for example, elements of arrays and hashes.

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

my %h = ( foo => 1 );

{
local $h{'foo'} = 2;
print Dumper \%h;
}

print Dumper \%h;
[download]

$VAR1 = {
          'foo' => 2
        };
$VAR1 = {
          'foo' => 1
        };
[download]

I would summarize by saying that As different as lexical variables are from package variables, so is local from my.
local is a run-time function, whereas my is a compile-time keyword (with some run-time effects).
local is very useful in its own way. It is by no means a drop-in replacement for my

We're building the house of the future together.

Comment on Re^2: local variable syntax Select or Download Code

Replies are listed 'Best First'.
Re^3: local variable syntax by fishbot_v2 (Chaplain) on Apr 27, 2006 at 14:31 UTC
Well, I said "basically" never. Like all blanket statements, there are exceptions. Perhaps I should have said: Use `my` by default, use `local` when you understand why you can't use `my` in a specific situation. You can create 'stack-like' aggregates with `local` as you demonstrate, but you need a very good reason. `# some good reasons: # if you modify a side-effect global like $/, # do it in the smallest scope possible: my $slurped = do { local $/; <$some_Fhand> }; # override an element of a global aggregate in a # limited scope: { local $SIG{"ALRM"} = \&some_handler; alarm $timeout; some_action(); }` [download] Of course, I agree that understanding the difference is much better than applying a blanket maxim. (Which is why I pointed to an article that does just that.)	[reply] [d/l] [select]
Re^4: local variable syntax by jdporter (Paladin) on Apr 07, 2011 at 16:54 UTC
Like all blanket statements, there are exceptions. But these aren't even exceptions. They are simply other first-class cases. Perhaps I should have said: Use my by default, use local when you understand why you can't use my in a specific situation. That would certainly be better, but, like your previous post, it begs the usage context. Which is, namely: When you want to declare a variable. `local` is not good for declaring variables. In fact, it simply does not do that at all! What it does (and this was pretty much your first and only line of defence in Perl 4) is let you safely use a prior existing global variable in your "private" scope. As long as all scopes follow the protocol of localizing their variables before use, global variables can work fine. But that's a big "if", and lexical variables (introduced in Perl 5) allow a great measure of safety which doesn't even depend on every scope abiding by the rules. I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.	[reply]