in reply to Re: Stashing a Package Variable by Reference
in thread Stashing a Package Variable by Reference

Your code is, I admit, more clever than mine. But if I understand correctly, you're setting up a hash in the stasher's symbol table. Since my case isn't really a script, that's not main and I might write something like: 

package Stasher; 

sub stash {
    my $ns = caller;
    $ns    = $ns . '::';
    ${ $Stasher::{$ns}{foo} } = 'cheese';
};

[download]

Before I hammered out my current approach, I considered a less clever one: 

package Stasher; 
our %stash_of;

sub stash {
    my $ns = caller;
    $stash_of{$ns}{foo} = 'cheese';
};

[download]

This resembles a flyweight object and suffers from a similar weakness, in that Stasher keeps %stash_of entries alive unless and until an explict DESTROY is called. That's okay for flyweights but in my case, how does Stasher know when caller's entire package has gone out of scope?

My thought was to stash $foo in caller's symbol table because I can rely on it being deallocated in Perl's own good time.

- the lyf so short, the craft so long to lerne -

Replies are listed 'Best First'.
Re^3: Stashing a Package Variable by Reference
by almut (Canon) on May 30, 2010 at 18:54 UTC
    But if I understand correctly, you're setting up a hash in the stasher's symbol table. Since my case isn't really a script, that's not main ...

    Not really sure what you mean.  Of course, the approach isn't limited to main — the latter is just the top-level stash that every "package path" is rooted at.

    Essentially, all I wanted to point out is that, in general 

        ${ $::{'PackageA::'}{'PackageB::'}{'PackageC::'}{foo} }

    [download]

    functionally achieves the same as your symbolic reference 

        ${ *{"PackageA::PackageB::PackageC::foo"} }

    [download]

    (which could be simplified to  ${"PackageA::PackageB::PackageC::foo"},  btw — or ${"$ns\::foo"} in your specific case)

    But, as the former approach doesn't involve symbolic references, it's compatible with use strict, i.e. it doesn't need no strict 'refs'.


    P.S.: in several places of the current version of your original node, you're missing the closing curly in the expression ${ *{"${ns}\::foo"}

[reply]
[d/l]
[select]

      Yes, almut, I completely missed what you were doing!

      Study-up on the web is amazingly difficult on this topic. Source after source discusses "symbol tables" (plural) and forks every other source, contrasting package variables vs lexicals; our vs local vs doing nothing at all; and of course speaking briefly about symbolic references before telling how to use strict so that they can't be used at all. Some sources go into bloody detail about the structure of a typeglob; I even found an interesting explanation of the internal C representation of variables.

      There is really (for some value of "really") only one symbol table! Careful reading of Camel tells:

      As it happens, the main symbol table contains all other top-level symbol tables, including itself...
      <cite>Programming Perl 2nd ed. 5.1.1</cite>

      I've experimented a bit with this now. Your code works and it's a vast improvement over what I had. This works too, under strict and warnings: 

      my $ns                  = 'Teddy::';
my $var                 = 'foo';
${ $::{$ns}{$var} }     = 'cheese';

      [download]

      ... which isn't a symbolic reference??

      I need to rewrite this entire node. Meanwhile, I bow to almut's superior code-fu.

      - the lyf so short, the craft so long to lerne -
[reply]
[d/l]
        There is really (for some value of "really") only one symbol table!

        Not really — or only if you add "per namespace/package". Somewhat simplified, you can think of it as a nested hash-of-hashes structure. For example, the package(s) Foo::Bar would be represented like 

        %:: = (
    'Foo::' => {
        'Bar::' => {
            varname => typeglob,
            ...
        },
        ...
    },
    ...
);

        [download]

        The main difference is that the values associated with the packagename keys like 'Foo::' aren't simple hashrefs, but rather typeglobs, whose hash slot points to the actual symbol table hash. But Perl has some DWIM magic in place for globs, i.e. if you treat it as a hashref, you'll get its hashref entry, which is why you can write $::{'Foo::'}{'Bar::'}{varname}, as if it were a HoHoH.

        I need to rewrite this entire node.

        Not necessarily  (all I would change is ${*{"${ns}\::foo"}} into the simpler ${"$ns\::foo"} or ${"${ns}::foo"} ).  Symbolic references are there for a reason.  While I would probably use the "non-symbolic" approach for simple static structures like your Teddy:: example, I would rather use symbolic references for more complex/arbitrary structures, (like you might get from caller), because creating a HoHo... access from something variable-depth like Foo::Bar::Baz::... is much too much work compared to locally saying no strict 'refs', and then simply using the string "Foo::Bar::Baz::..." as is...

[reply]
[d/l]
[select]

        ... which isn't a symbolic reference??

        Yes, but it's not any safer than symbolic reference. Given that symbolic references are easier to use, you might as well use those instead of messing with %::.

        Compare 

        my $r = do {
   no strict 'refs';
   \${"${pkg}::$var"}
};

        [download]
        with 
        my $r = do {
   $pkg_ref = $r->{$_."::"} for split(/::/, $pkg);
   \($pkg_ref->{$var})
};

        [download]
[reply]
[d/l]
[select]
      Why on earth are you reinventing symbolic references, only to be able to use strict everywhere??

      There is a reason why symbolic references exist in Perl, and that is to avoid having to juggle with complex manipulations like yours. Symbolic references is the simple and thus the proper approach for this kind of application.

      All you have to do is to locally disable use strict (or at the very least use strict 'refs') by making a small enclosing block, and put 

      no strict 'refs';

      [download]
      in there.

      Even though using direct manipulation of the stashes bypasses strict, that does not imply that it's the better approach.

      You just have to know when it is a proper time to break the rules.

[reply]
[d/l]
[select]
        having to juggle with complex manipulations like yours

        What complex manipulations?  In essence, what I originally suggested as an alternative was 

        ${ $::{$ns}{foo} } = ...

        [download]

        in place of 

        { 
    no strict 'refs';
    ${ "${ns}::foo" } = ...
}

        [download]

        I fail to see how that is any more complex.  Neither did I say anything about it being "better" in general.

[reply]
[d/l]
[select]

In Section Meditations