Front page | perl.perl5.porters |
Postings from May 2003
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