go ahead... be a heretic | |
PerlMonks |
Re: Undefining symbol tables and globs and things, oh myby Bob9000 (Scribe) |
on Aug 10, 2005 at 12:46 UTC ( [id://482590]=note: print w/replies, xml ) | Need Help?? |
How does perl know how to find $Yakkity::Yak::a after the package's symbol table is gone?
It doesn't. However, it seems to compile $Yakkity::Yak::a as a hard reference to a specific entry in the symbol table, allowing that glob and the variables it references to continue existing after it has been removed from the table. Notice that after undeffing the symbol table, attempting to access the variable with a soft reference (i.e. ${"Yakkity::Yak::a"}), or with a direct reference in any code compiled later (i.e. eval '$Yakkity::Yak::a'), will fail...although compiling the new code (or accessing a soft reference) will create another variable named $Yakkity::Yak::a, which is unrelated to the one referenced by code compiled before the undeffing. A demo:
This outputs the following:
The first eval creates a glob *x::a in the symbol table, compiles both of its own $x::a accesses as references to that glob, then removes it from the symbol table upon executing the undef statement. As a result, there are no entries remaining in the symbol table, so t1 shows nothing. The third eval (t2) creates another glob named *x::a in the symbol table, prints the symbol table (showing *x::a still inside), and assigns the new $x::a a value. The fourth eval (t3) compiles its $x::a as a reference to the one currently in the symbol table, then accesses the original $x::a through a subroutine which was compiled with a reference to it, and prints both. (yak could just as well have been defined before any of the evals, since all that matters is that its compilation occurred before the undef was executed.) Looking back at this post, I probably should have stopped after two sentences. But then, I had a little too much fun playing with this not to make a few notes.
In Section
Seekers of Perl Wisdom
|
|