[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