Re: Re: "my" variables going public?

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?

Comment on Re: Re: "my" variables going public?

Replies are listed 'Best First'.
(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]

Replies are listed 'Best First'.

(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]