[sf-perl] oddity with an exported and localized variable
Joe Brenner
doom at kzsu.stanford.edu
Mon Nov 30 19:56:18 PST 2009
Earl Ruby <eruby at knowledgematters.net> wrote:
> 2009/11/26 yary <not.com at gmail.com>:
> > Based on the perlsub section "Temporary Values via local()":
> > A "local" modifies its listed variables to be "local" to the
> > enclosing block, "eval", or "do FILE"--and to any subroutine
> > called from within that block. A "local" just gives
> > temporary values to global (meaning package) variables. It
> > does not create a local variable. This is known as dynamic
> > scoping. ...
> >
> > Emphasis is in the original perldoc. So it looks like a bug to me
> > too. Bring it to the monks.
> Maybe I'm missing something here, but for the localized variable,
> doesn't "the enclosing block and any subroutine called from within
> that block" include all of the print statements after the local
> declaration and the check_value_local_def sub?
That sounds right to me. Are you saying that you don't see why
we think the behavior is odd?
A localized value is supposed to be in effect inside of the subroutines
called from inside of that scope. The local is still in effect when
we call "check_value_exported_sub", so why isn't it what that sub sees?
> FWIW, output is the same under Perl 5.8.8 as 5.10.0:
>
> initial value: initial
> the new value: new value
> check_value_exported_sub sees:
> exported_variable: initial <-* this is the weird one
> check_value_local_def sees:
> exported_variable: new value
> For the "our" variables in the module
> (http://perldoc.perl.org/functions/our.html):
>
> "our associates a simple name with a package variable in the current
> package for use within the current scope. When use strict 'vars' is
> in effect, our lets you use declared global variables without
> qualifying them with package names, within the lexical scope of the
> our declaration. In this way our differs from use vars , which is
> package scoped."
>
> "Unlike my, which both allocates storage for a variable and associates
> a simple name with that storage for use within the current scope, our
> associates a simple name with a package variable in the current
> package, for use within the current scope. In other words, our has the
> same scoping rules as my, but does not necessarily create a variable."
All of this sounds right too, what point do you think is significant?
In the sub, we've got a variable entry in the symbol table, and
we're also exporting it to the symbol table of the calling script.
We do a local on that one, and it effects the exported one,
but not the one back in the original package.
Note that if you just do a glob assignment to create the alias
yourself, a local on one also effects the other, and yet there
appears to be something funny happening when Exporter creates
the alias.
More information about the SanFrancisco-pm
mailing list