It's worth noting as well that CHECK and END blocks give the same results as we see in INIT. So in some way those portions of a program's lifespan are privileged. Also, whether the variables have attributes is incidental to whether peek_my can see them at runtime, for example,
{ package Baz; my %baz; }
likewise only shows up when dump_lex is called from the special execution blocks.
Now, a standalone my %quux is visible no matter where dump_lex is called from. This makes me think that perhaps there is loophole in PadWalker, and that there is still a way to keep your lexicals private; namely, by relying on perl's runtime enforcement of scope which I guess is just the same mechanism that makes it possible to write:
sub foo { my $foo; { my $foo; } }
That is to say, at runtime perl knows to differentiate the two $foos based upon where they are declared, despite being written on the same pad.
Update: Duh. This isn't a loophole, but rather the documented, intended behavior. From the docs: It will only show those variables which are in scope at the point of the call. I must have read that line 10 times and it only made sense when I was about to step in the shower :)
In reply to Re: Re: Lexical pad / attribute confusion
by djantzen
in thread Lexical pad / attribute confusion
by adrianh
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |