Dumping symbol table shows variables declared with our but not my

Popcorn Dave has asked for the wisdom of the Perl Monks concerning the following question:

Fellow monks,

Given the following code:

use strict;

my ($x, $y, $z);

sub dispSymbols {

    my($hashRef) = shift;
    my(%symbols);
    my(@symbols);

    %symbols = %{$hashRef};
    @symbols = sort(keys(%symbols));

    foreach (@symbols) {
        printf("%-10.10s| %s\n", $_, $symbols{$_});
        }
    }

dispSymbols(\%main::);
[download]

The variables $x, $y and $z are not showing up in the dump. However if I change the my to our then they do show up. The rest of the symbol table does show up as I expected.

Can someone please explain to me why this is happening?

Thanks in advance!

Useless trivia: In the 2004 Las Vegas phone book there are approximately 28 pages of ads for massage, but almost 200 for lawyers.

Comment on Dumping symbol table shows variables declared with our but not my Download Code

Replies are listed 'Best First'.
Re: Dumping symbol table shows variables declared with our but not my by Happy-the-monk (Canon) on Oct 11, 2004 at 00:17 UTC
The variables you declared with `my` are lexically scoped variables. They do not live in the `package main`, hence you cannot see them there; That is what lexicals and the `my`-keyword are all about. See Variable scoping in `perldoc perlintro` for a first glance and Private Variables via my() in `perldoc perlsub` for better explanation of `my`. Edit: added links to perlsub which has better documentation. And the following: `perldoc -f our` says that the variable is part of the package. Cheers, Sören	[reply]
Re^2: Dumping symbol table shows variables declared with our but not my by Popcorn Dave (Abbot) on Oct 11, 2004 at 02:36 UTC
Thanks for cleraring up my misconceptions. I was always under the assumption that if it's not in a module, it's in main:: Useless trivia: In the 2004 Las Vegas phone book there are approximately 28 pages of ads for massage, but almost 200 for lawyers.	[reply]
Re^3: Dumping symbol table shows variables declared with our but not my by revdiablo (Prior) on Oct 11, 2004 at 16:46 UTC
I was always under the assumption that if it's not in a module, it's in main:: That's true for package variables, but lexical variables (the kind you get when you use my) are not package variables. They don't live in any package at all.	[reply]
Re: Dumping symbol table shows variables declared with our but not my by davido (Cardinal) on Oct 11, 2004 at 02:41 UTC
Globals live in the package global symbol table. Lexical variables do not reside in the package global symbol table. They are held in a sort of internal pad. my variables (actually known as lexical variables) have their own private namespace, so to speak. our is a kind of new-fangled way to declare package globals within a particular scope. It really has little effect unless you're using strict. But they're definately not the same thing as lexicals. You can't have two 'our $this' in the same package namespace and expect them to be different variables. They're the same variable. Consider the following code: `{ our $global = 10; # Declare a package global. my $lexical = 10; # Declare a block-scope lexical. { our $global = 20; # Redeclare same package global. my $lexical = 20; # Declare a new lexical in narrower scope +. } # Narrower scope has ended. Inner $lexical disappears. # $global remains. print "Global: $global\nLexical: $lexical\n"; } __OUTPUT__ Global: 20 Lexical: 10` [download] Since there is only one symbol table per package, that package global declared with our is the same one throughout this script. But there can be as many different lexical variables of the same name as there are scopes to fit them in; each one is in its own namespace, which we (without XS) don't really have access to. By the way, the variable declared by `our $global` is the same variable as `$main::global`, and `$::global`, and `${$::{global}}` (assuming we're in package main). Each syntax has its own uses, but we don't usually see some of them in everyday code. Dave	[reply] [d/l] [select]