Dave Mitchell <davem@fdgroup.com> writes: >> >Any gotchas? >> A. How deep do you search? - if expression is deep and involves lots >> of closures or whatever this could take a while if 1st 100,000 >> variables are all defined. > >The search is a shallowish search of the kids of the offending op. >Closures etc shouldn't make a difference, as its not searching pads, its >searching ops. It should only check a couple of vars for a binary op. So when doing this: my $j = 10; $foo = sub { shift(@_) + $j }; $result = (($a+$b)*($c+$d))+(($g+$h)* &$foo($i)); and $i is undef - you find undef scanning the '+' op in the closure but don't know it is $i? > >> B. IIRC geting names of pad variables at run-time is tricky - the names >> are there in compile phase. > >This is easy now with Perl_find_runcv(), which was added as part of a fix >to allow eval to see the full lexical scope. Ah - must look at that - The snag cam up back when I was looking for lexical names to give sensible name to the file-handle that gets created on: open(my $fh,...) -- Nick Ing-Simmons http://www.ni-s.u-net.com/Thread Previous | Thread Next