Phoenix.pm: definedness and more symbol tables
Beaves at aol.com
Beaves at aol.com
Fri Jan 21 17:14:36 CST 2000
I just thought I'd share some stuff I learned with y'all during my symbol
table excursion. Some of the testing on my little sub did not go as
expected. I couldn't understand why, but I think I figured it out.
If there is something that I say here that is in dispute, please bring it up.
(I'm using package 'main' for all examples...)
On initial parsing of a program, symbol table entries are made for each
symbol (I'm guessing for efficiency). Even if there is no assigment, there
will be a
$main::{symname}
entry made to the symbol table, and a reference to the variable created.
For instance, just saying.
@symname;
creates
$main::{symname}
and a reference to the ARRAY for symname in the glob.
*main::symname{ARRAY}
Of course, the value it is pointing to is still undefined, but
*main::symname{ARRAY} is itself defined.
Hashes and Arrays are 'undefined' until the memory is allocated for them.
This is an interesting point. See below
@symname; #undefined
@sumname = (); # still undefined;
@symname = (1) # now its defined...
# but if you say
shift(@symname); # @symname is STILL DEFINED
# even if you say
@symname = undef; #@symname is STILL DEFINED (memory still allocated)
# same is true for hashes
The definedness of subroutines has to do if the code was successfully parsed.
Saying
defined $symname;
will not create a symbol table entry. However, if this statement is made on
parsing, it WILL create a symbol table.
Consider...
defined $symname; # symbol table entry created on parsing this code, not
when running it
delete( $main::{symname});
defined $symname; # does not create a symbol table entry.
This stuff is not really that important, but I thought that I'd share what I
discovered.
Sorry for boring you'all to tears.
See you round campus.
Tim
More information about the Phoenix-pm
mailing list