in reply to Re: Re^4: Lexical pad / attribute confusion
in thread Lexical pad / attribute confusion

Actually I get different results. On 5.6.1 (win32) lexicals declared after INIT are not visible from INIT.

My results on 5.8 match yours if I run your code. Not surprising since your code is different from mine :-)

dump_lex climbs up the callstack to the enclosing file lexical scope. So it would be the same sort of thing as doing this:

use warnings; use strict; INIT { use Data::Dumper; use PadWalker qw (peek_my peek_sub); print Dumper(peek_my(1)); } my $foo = 'lee'; my $bar = "Bar"; print Dumper(peek_my(0)); { my @foo = (1..3) }; { my @bar = (9..12) }; print Dumper(peek_my(0));

Which gives (on 5.8)

$VAR1 = { '$foo' => \undef, '@bar' => [], '@foo' => [], '$bar' => \undef }; $VAR1 = { '$foo' => \'lee', '$bar' => \'Bar' }; $VAR1 = { '$foo' => \'lee', '$bar' => \'Bar' };

Again, INIT can see everything, but nothing can be seen before/after the blocks are executed at the top level. I still don't understand what's happening here :-)

Replies are listed 'Best First'.
Re: Re^6: Lexical pad / attribute confusion
by shotgunefx (Parson) on Dec 22, 2002 at 01:44 UTC
    Which brings this doozie that I previously struggled with. Why can't peeker see @bar ?
    use warnings; use strict; INIT { use Data::Dumper; use PadWalker qw (peek_my peek_sub); print Dumper(peek_my(1)); } my $foo = 'lee'; my $bar = "Bar"; sub peeker{ print Dumper(peek_my(shift)); } print Dumper(peek_my(0)); { my @foo = (1..3) } { my @bar = (9..12); peeker(1); } print Dumper(peek_my(0)); __END__ $VAR1 = { '$foo' => \undef, '@foo' => [], '$bar' => \undef, '@bar' => [] }; $VAR1 = { '$foo' => \'lee', '$bar' => \'Bar' }; $VAR1 = { '$foo' => \'lee', '$bar' => \'Bar' }; $VAR1 = { '$foo' => \'lee', '$bar' => \'Bar' };
    I don't know enough to say for sure, but when INIT is called, the pad accesses are probably all figured out. Then after INIT, it does whatever magic it does to give the appearence of a scope to a bare block. I would think that even though they are unavailable to the outer scope, their position is retained in the pad list. Otherwise the location of a my var would change from before and after the bare block.

    -Lee

    "To be civilized is to deny one's nature."
      Which brings this doozie that I previously struggled with. Why can't peeker see @bar ?

      Running perl 5.8 and PadWalker 0.08 you do!

      $VAR1 = { '$foo' => \undef, '@bar' => [], '@foo' => [], '$bar' => \undef }; $VAR1 = { '$foo' => \'lee', '$bar' => \'Bar' }; $VAR1 = { '$foo' => \'lee', '@bar' => [ 9, 10, 11, 12 ], '$bar' => \'Bar' }; $VAR1 = { '$foo' => \'lee', '$bar' => \'Bar' };

      Are you using the same version of PadWalker?

        You are correct, it's been fixed. Using 5.6 with PadWalker 0.8 on my 'nix box it works fine. Previously it did not. (The script I originally tested the code for this post on was 5.6.1 Win32 with PadWalker 0.5)

        -Lee

        "To be civilized is to deny one's nature."