in reply to funky $_ with map {}

Yes, this is a scope issue. Consider this:
my %hash = map {$_ => sub {return "<H1>$_</H1>"} } (1..5); $_ = 'foo'; print &{$hash{2}};
Do you really need anonymous subs to solve your problem? Would this work instead?
my %hash = map {$_ => "<H1>$_</H1>" } (1..5);
Seems much more simple and usable to me ...

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Replies are listed 'Best First'.
Re: (jeffa) Re: funky $_ with map {}
by Anonymous Monk on Mar 02, 2002 at 20:37 UTC
    no that wouldn't work.

    I wouldn't be using sub's unless I needed to use subs.

    I thought it was kind of ghetto to have to resort to eval to get $_ to be have properly (yeah I knew it was global, but it should've been local to block, and once the sub's were compiled, IMHO, it shouldn't need to stay shared).

    Thanks anyway

      Eval is probably not as bad as you think. If the little extra compilation overhead is a significant portion of your program's run time, you probably shouldn't be building this coderef laden hash anyway.

      Local creates a temporary copy of the variable, but it stays global, so there's no reference count increased when you use it in the anonymous sub. When the scope ends, the temporary copy is simply discarded.

      my creates a new lexical, our is a lexically scoped "use vars", local creates a temporary copy of the global that will be used while the lexical scope lasts.
      Only lexicals can stay shared.
      (I have probably made some mistakes or mis-assumptions. If you see any, please do correct me)

      Lbh ebgngrq guvf grkg naq abj lbh pna ernq vg. Fb jung? :) -- Whreq