Re: "my" variables going public?

my variables don't live in a symbol table, and so don't have fully qualified names.

Package variables (aka package globals) do, and do respectively.

package foo;
my $foo = 'bar';
[download]

does not set $foo::foo. The call to set $foo in the subroutine sees only the my variable, because the use of my to declare a $foo masks the package global.

Note also that this 'masking' works even through different packages. my variables are visible within their scope, which can cross package boundaries.

That makes sense, because one always has a way of accessing $foo::foo with a fully qualified name, but you won't have that with my.

does that help?

Comment on Re: "my" variables going public? Select or Download Code

Replies are listed 'Best First'.
Re: Re: "my" variables going public? by DeaconBlues (Monk) on May 21, 2001 at 23:30 UTC
So for my example module foo.pm, $bar and $foo::bar are completely separate variables. And anywhere you access $foo::bar you will never get any value attached to $foo. Correct?	[reply]
(arturo) Re (3): "my" variables going public? by arturo (Vicar) on May 21, 2001 at 23:54 UTC
`$foo::bar` is set in the subroutine in `foo.pm`. So it's visible everywhere after that subroutine is executed, as `$foo::bar`. The `$foo=6;` in that sub sets the `my` variable to 6. You get an uninitialized value error at line 7 because you haven't called `foo:set_foobar` yet, but the next time you try to print out that value (at line 13), you have. You code, as it stands, never sets `$foo::foo`. And, unless it is the return value of a sub in `foo.pm`, you'll never be able to see the value of that `my` variable in any code that lives outside `foo.pm` For more goodness on this stuff, check out Dominus' home node and follow the link to "Coping With Scoping". HTH	[reply] [d/l] [select]