in reply to Re: File-scoped lexicals and eval scope?
in thread File-scoped lexicals and eval scope?

%map and $value go out of scope, but are not freed, since initialize closes over %map which references $value. But since the implicit file scope was exited and initialize does not close over $value, in the call to initialize, $value is no longer bound to initialize's %map's ${$map{value}} and so is "not available". Correct?

Inserting a $value if 0; into sub initialize to make it close over $value and correcting the 'ex'/'example' inconsistency makes it work (both on 5.8.x and 5.10).

Replies are listed 'Best First'.
Re^3: File-scoped lexicals and eval scope?
by jbert (Priest) on Nov 09, 2007 at 11:12 UTC
    Good analysis on what was happening to $value.

    But if the OP wants persistent, file-scope variables, I'd say that package variables are a better choice.

    Changing the 'my' to 'our' would arrange that and be more readable than relying on tricks like 'if 0', imho.

[reply]
[d/l]
      That's the conclusion that we came to, finally, which is why the "fix" worked. It just didn't seem to be very intuitive with what we thought we knew about file-scoped lexicals. I never use package variables for this sort of thing, since those can be changed from anywhere, and I really don't like tracking down "action from a distance" issues. In this case, though, it may be the right solution. Thanks for the suggestion! Cambo
[reply]
      I guess I don't consider $value if 0; a trick. The idea is that, if sub initialize wants to have its use of $value be bound to the outer lexical even after that lexical's scope is exited, it needs to explicitly mention it. scalar($value); works as well, as does 0 if $value;.  Any of them should be accompanied by a comment. If you want to be pedantic, the latter is best documented as not triggering a 'Useless use' warning.
[reply]
[d/l]
[select]
        I called it a trick because it exploits undefined behaviour in the language. perl 5.10, 5.12 or some future version may or may not preserve the same behaviour, so it seems to me bad practice to promulgate it's use.

        As I'm sure you know, perldoc perlsyn states:

        NOTE: The behaviour of a "my" statement modified with a statement modi‐ fier conditional or loop construct (e.g. "my $x if ...") is undefined. The value of the "my" variable may be "undef", any previously assigned value, or possibly anything else. Don’t rely on it. Future versions of perl might do something different from the version of perl you try it out on. Here be dragons.

[reply]

In Section Seekers of Perl Wisdom