Re: do, local and a qualified identifier?

I thought it gave it a global symbol a local value?

It does, at run-time.

Foo.pm gets compiled.
Foo.pm's topmost level gets executed.
- local $Foo::bar gets executed.
  - $Foo::bar current value (undef) is saved.
  - $Foo::bar is set to undef.
- Anything else in Foo.pm's topmost level gets executed.
- $Foo::bar reverts to undef. A file counts as block for scoping purpose, and we've just run to the end of the block in which local $Foo::bar was called.
&Foo::init is called.
&Foo::init sets $Foo::bar to 42. There's no local $Foo::bar in effect, so the value remains.

What is the purpose of the declaring $Foo::bar local?

None, unless it's used in Foo.pm's topmost level, or in a function (directly or indirectly) called from Foo.pm's topmost level.

If so, when init is called will it set the localized value like a closure or the global value?

It depends on whether someone in the call stack did local $Foo::bar. Unless &Foo::init is called from Foo.pm's topmost level (where there is such a local), probably not.

Further, what is the point of qualifying the identifier with the package name? and does that have any effect on the functionality?

Removing it will result in a compilation failure because use strict 'vars' is active. If you want to remove the need for the package quantifier, use our $bar; in scope at compile-time.

use strict;
use warnings;

package Foo;

our $bar;  # "our" is like "my", but it
           # creates a package variable
           # instead of a lexical variable.

sub init {
    $bar = 42;  # "our" removes the need to
                # specify the package name.
}

...

1;
[download]

Comment on Re: do, local and a qualified identifier? Select or Download Code

Replies are listed 'Best First'.
Re^2: do, local and a qualified identifier? by pg (Canon) on Oct 09, 2005 at 03:22 UTC
The last part of your post might misled people to think that our is a must for removing the syntax error. So just a little bit more detail... Remove the package qualifier, but keep local, it results syntax error: `use strict; use warnings; package Foo; local $bar; sub init { $bar = 42; } 1;` [download] `Global symbol "$bar" requires explicit package name at Foo.pm line 6. Global symbol "$bar" requires explicit package name at Foo.pm line 9. Global symbol "$bar" requires explicit package name at Foo.pm line 10. Foo.pm had compilation errors.` [download] But use either my or our removes the error: `use strict; use warnings; package Foo; my $bar; sub init { $bar = 42; print $bar; } 1;` [download] But the use of our or my does make difference in other sense. The following script works when $bar is defined with our: `use strict; use warnings; use Foo; Foo::init(); print $Foo::bar;` [download] But does not work if $bar is defined with my: `Name "Foo::bar" used only once: possible typo at math1.pl line 7. Use of uninitialized value in print at math1.pl line 7.` [download] my or our? depends on what you want to do - in what scope you want your variables to be seen.	[reply] [d/l] [select]
Re^3: do, local and a qualified identifier? by ikegami (Patriarch) on Oct 09, 2005 at 16:36 UTC
yeah, but using `my` would render `$bar` inaccessible from the main program. Since the OP was asking for the value of $Foo::bar as seen from the main program, using `my` probably won't work. Thanks for the clarification, though.	[reply] [d/l] [select]