Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Creating "Lexical" Symbol Table Aliases (a la "use vars") From The Same Package

by OneTrueDabe (Acolyte)
on May 08, 2014 at 16:50 UTC ( #1085478=perlquestion: print w/replies, xml ) Need Help??

OneTrueDabe has asked for the wisdom of the Perl Monks concerning the following question:

So I don't know if this belongs in SoPW or Meditations, but I stumbled across the following (what I would call) inconsistency, and wondered if anybody had an explanation...

This does not work:
use strict 'vars'; BEGIN { *main::foo = \@main::foo } print "Foo: (@foo)\n"; __OUTPUT__ Variable "@foo" is not imported at line 10. Global symbol "@foo" requires explicit package name at line +10. had compilation errors.
But this works fine:
use strict 'vars'; package somePkg; BEGIN { *main::foo = \@main::foo } package main; print "Foo: (@foo)\n";
Somewhat interestingly, this seems to work okay, too:
use strict 'vars'; # We're already in package main BEGIN { *pkg::foo = \@pkg::foo } package pkg; print "Foo: (@foo)\n";
And this fails, as well:
use strict 'vars'; package pkg; BEGIN { *pkg::foo = \@pkg::foo } print "Foo: (@foo)\n";
I noticed that running "perl -MO=Deparse" on the last snippet, above, shows the symbol table manipulation being (*cough*) "optimized" (*cough*) thusly:
package pkg; sub BEGIN { *foo = \@foo; }

Perhaps that's why "strict" doesn't allow me to access the unqualified "@foo" directly? Because -- since it's not in a different package -- something, somewhere, isn't creating the corresponding lexical alias? *Shrug*

Finally, this is mostly the same as number 2, above, which also works, but in the fewest lines:

use strict 'vars'; BEGIN { package pkg; *main::foo = \@main::foo } print "Foo: (@foo)\n"; __OUTPUT__ Foo: ()

PS - Before you say "Just use 'our'" ...

Yes, I know. There's More Than One Way To Do It, and I'm MORE curious about the underlying question of why THIS way happens to fail.

Thanks! :-D

Replies are listed 'Best First'.
Re: Creating "Lexical" Symbol Table Aliases (a la "use vars") From The Same Package
by tobyink (Canon) on May 08, 2014 at 17:34 UTC

    Yes, I've stumbled upon this before and found it odd. The closest thing I can find to documentation for it is in perlmod:

    "The results of creating new symbol table entries directly or modifying any entries that are not already typeglobs are undefined and subject to change between releases of perl."

    ... which may or may not cover this situation.

    It seems to be that if the symbol table is being manipulated by code in another package, Perl thinks you're importing a variable, and treats that as "as good as a declaration", but if it's manipulated by code within the same package, it doesn't.

    Sorry if that's a bit of a non-answer.

    Update: take a peek at this:

    use Devel::Peek; BEGIN { *main::foo1 = []; package X; *main::foo2 = []; }; Dump($_) for \*main::foo1, \*main::foo2;

    In particular, look at the FLAGS.

    use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
Re: Creating "Lexical" Symbol Table Aliases (a la "use vars") From The Same Package
by moritz (Cardinal) on May 09, 2014 at 08:42 UTC

    The proper way to do lexical aliases it through explicit references.

    Sadly that means you need an explicit dereferencing step when using the local alias/reference.

    On the upside, explicit dereferencing makes it clear that "action at a distance' (changes in local data are propagated to the original data location, and vice versa) is happening. so it might not be a bad thing.

    Finally, Lexical::Alias exists (haven't used it yet).

Re: Creating "Lexical" Symbol Table Aliases (a la "use vars") From The Same Package
by LanX (Sage) on May 08, 2014 at 19:59 UTC
    I don't think this has anything to do with lexicals, but with importing package vars.

    AFAIK you are reproducing the import mechanism 100% (a glob from one STASH gets a reference to a fully qualified package var assigned)

    Apparently Perl is setting a flag then, indicating that the target $var doesn't need to be oured anymore under strict.

    The only "special" thing is that you found a back-door to import from the same package.

    The first example that doesn't work seems to highlight an implementation detail, that the surrounding package has to be different (which is quite normal during imports)

    I will try to update this post with a test script emphasizing my theory... or you can just have a look into Exporter.


    PS: considering your *coughing*: compilation is a two phase process, the package-declaration is done before BEGIN is executed, hence the output of B::Deparse is correct.¹

    Cheers Rolf

    ( addicted to the Perl Programming Language)


    just realized that tobyink++ practically gave the same answer. :)



    > perl package TST; BEGIN { $a=42 } package main; print $TST::a; __END__ 42
Re: Creating "Lexical" Symbol Table Aliases (a la "use vars") From The Same Package
by Anonymous Monk on May 09, 2014 at 00:38 UTC

      Those bits of source show how strict vars works, but what I'm more interested (and couldn't figure out) is which part of the code determines whether or not a glob assignment will result in setting the IMPORT flag on the GV.

      Which bit of code does it? And is there a great big comment by that code explaining why it's done the way it's done?

      use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
Re: Creating "Lexical" Symbol Table Aliases (a la "use vars") From The Same Package
by karlgoethebier (Abbot) on May 08, 2014 at 17:38 UTC
    "What is it good for? Absolutely nothing!" (Edwin Starr)

    Or do i miss something?

    Best regards, Karl

    «The Crux of the Biscuit is the Apostrophe»

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1085478]
Front-paged by Corion
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (3)
As of 2022-01-20 16:34 GMT
Find Nodes?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:

    Results (57 votes). Check out past polls.