Using my with a modifier is skating on thin ice. While it works on the right side of the for it does bizarre (or at least counterintuitive) things on the left side. In an if the behaviour verges on the undefined (yes i know all about the static var effect.)
The fact is however that B::Deparse has long gotten the scoping effects of a for modifier wrong. Consider:
D:\Development>perl -MO=Deparse -e "my $x=$_ for 1..10;" foreach $_ (1 .. 10) { my $x = $_; } -e syntax OK
The $x is not scoped to the for loop. Its scoped to the container of the for loop. Its also not so great at the scoping effects of the if modifier either:
D:\Development>perl -MO=Deparse -e "my $x=1 if 0; my $y=1 if 1;" '???'; my $y = 1; -e syntax OK
Re: Re: 'my' headache...Why Deparse is Wrong. and Regarding B::Deparse both discuss errors like this.
The moral of the story is essentially don't trust deparse. :-) Its a useful tool, but blindly assuming it is correct will just muddle your brain.
Btw, a little trick:
use Data::Dump::Streamer; use Data::Dumper; my ($x,$y,$z); print Dump($_,$x,$y,$z),"\n" for $x,$y,$z; print Dumper($_,$x,$y,$z),"\n" for $x,$y,$z; __END__ $VAR1 = undef; alias_ref(\$VAR2,\$VAR1); $VAR3 = undef; $VAR4 = undef; $VAR1 = undef; $VAR2 = undef; alias_ref(\$VAR3,\$VAR1); $VAR4 = undef; $VAR1 = undef; $VAR2 = undef; $VAR3 = undef; alias_ref(\$VAR4,\$VAR1); $VAR1 = undef; $VAR2 = undef; $VAR3 = undef; $VAR4 = undef; $VAR1 = undef; $VAR2 = undef; $VAR3 = undef; $VAR4 = undef; $VAR1 = undef; $VAR2 = undef; $VAR3 = undef; $VAR4 = undef;
Which even if it shameless advertising shows why use()ing Data::Dump::Streamer when debugging stuff can be a lot nicer than the other tools around.
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
In reply to Re^6: To initialise or not to initialise?
by demerphq
in thread To initialise or not to initialise?
by kiat
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |