local *HANDLE;
local $SIG{ALRM} = 'ignore';

my $x = 2;
################# UPDATE #######################
## Without removing my mistake above, so that
## anybody reading this node will note how
## silly (see Dominus's generous -cough- reply)
## I was (and I was silly to post code that I
## would never actually use and hadn't tested
## in a negative response to an almost saintly monk).
##
## The reason the code failed is because
## I need to do something like:
## use vars qw($x);
##  OR
## $main::x;
## Otherwise, local will fail (as per ctl's reponse)
## because it doesn't have access to "my"ed variables.
## It won't fail on the grounds that you shouldn't use
## local.
##
## Dominus didn't answer the response.
## There are still times when you need to use local
## (and saying only use IO::Handle or Symbol::gensym() or
## don't use SIG's is not an appropriate answer -- 
## sometimes we have no choice but to use FILEHANDLES
## and SIG's)
##
## Meanwhile maybe I should post a meditation about 
## answering with answers and not predispositions.
################# UPDATE #######################
sub A {
  local $x = 3;
  &B;
}
sub B{ $x }

print &A; #prints 3 not 2
[download]

Says Rhandom:

  my $x = 2;
  sub A {
    local $x = 3;
    &B;
  }
  sub B{ $x }

  print &A; #prints 3 not 2
[download]

No, it doesn't do that. Too bad you didn't try it!

"Always use my, never use local" is advice for people who don't understand the complexities yet. It's like the rule your mom told you about not talking to strangers. Is it always wrong to talk to strangers? No, of course not. Can a little kid be trusted to know when the rule doesn't apply? No.

So until Jemts can read those tutorials and understand what they mean, he's better off following the rule. You might be better off also---it would at least stop you from saying silly things on Perlmonks.

--
Mark Dominus
Perl Paraphernalia

Actually, all he has to do is:

sub A {
  local $x = 3;
  &B;
}
sub B{ $x }
my $x = 2;

print &A; #prints 3 not 2
[download]

And it does print 3 rather than 2. The order that he had it in would produce the error "Can't localize lexical variable $x at foo12.pl line 4." However, moving down, as I have done above, illustrates the point that the previous poster made.

As for the advice for newcomers to perl, I think that you're right. Using my() instead of local() in all cases until you've learned the intracacies is indeed good advice. However, weren't you a bit harsh to the previous poster as they made a simple mistake about where they put a line? While it's always good to provide good advice for a person's skill level, it's also good to not give the original poster the impression that local() is a bug which should be gotten rid of. Simply adding "until you understand the intricacies of local()" would suffice quite nicely to not risk turning the guy off to ever investigating local().


With humble thanks,
    -Chris
--
"They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown." -- Carl Sagan

and when each should be used?

That's easy: Always use my, and never use local.

Given Ovid's recent diatribe on questioning authority, I am going to call you on this one. I understand your wanting to make a simple answer here, but there is a slightly less simple but infinitely more valuable way to put this. "Always use my unless you are localizing a perl internal variable, such as one from perldoc perlvar." I think newbies will understand that they are not localizing a perl variable, and probably will glaze over it if it isnt applicable. To those whom it is applicable, they will understand right away that at the least they need to do something different, and hopefully ask a question.

For further clarity, I'd like to point out merlyn's excellent catch here, Re: Re: Re: Optimization for readability and speed (discussion), wherein he caught me messing about with $" when I should have been using local but wasnt. The node is in a simple context that I think most perl hackers can understand, even something-above-brand-new-newbies-to-perl'ers.

yours in perl
brother dep.

--
Laziness, Impatience, Hubris, and Generosity.

Do you think that localizing special variables is something that needs to be encouraged in Perl beginners?

Just to be clear, if you are going to change them, you should definitely localize them. If you are unclear on what I mean, read the very response of merlyn's that you are waving around.

When you are done that question, do you think it is good to lie to people and say that the only legitimate reason for calling local is to modify special variables?

In general I am with Dominus. Unless your knowledge level is to the point where you understand why you don't have any real choice but to call local, you should try to figure out how to solve your problem while calling my.

Actually, I think that it is important to know how to use local() for special variables like $/, $_, and $SIG{INT}. Maybe not for absolute beginners, but then I personally wouldn't thrust my() on absolute beginners, either.

In fact, I'm teaching a Perl class where I work, and I finally got around to demonstrating my() today. And this was my 11th class. (After all, I had to discuss how to use variables and write blocks of code, before I got into making variables private!) Although I didn't show them the local() command today, I probably will soon -- with an introduction just like deprecated used.

And I believe that deprecated's post worded the situtation wonderfully. An absolute beginner would know to leave the local() function alone, but the description was also precise enough that others might learn even more. It doesn't hurt to be precise, as long as an explanation doesn't become too confusing. In this case, I thought it was pretty darned clear.

buckaduck