http://qs1969.pair.com?node_id=96784

The bug recently discussed in Unusual Closure Behaviour is considered something of an oddity, with little practical value, but here's what I believe is a valid and defensible use of it, specifically with regards to mod_perl, and more generally with regards to any tool that wraps scripts into callable subroutines/hooks.

Those of you who've developed for mod_perl know that it's a bad idea to create global lexical variables in your Apache::Registry scripts, since they do not stay shared when mod_perl wraps your code into a subroutine. For example, under mod_perl, the following script is transformed from:
#!/usr/bin/perl -w ... my $fname = $q->param('fname'); my $lname = $q->param('lname'); ... sub foo { my $name = $fname.$lname; ... }
into a subroutine like this:
sub handler { ... my $fname = $q->param('fname'); my $lname = $q->param('lname'); ... sub foo { my $name = $fname.$lname; ... } }
As you see, foo() becomes one of those pesky inner named subroutines, which means that upon successive invocations of the script (or more precisely, the handler subroutine), the $fname and $lname variables of the inner sub will remain bound to their values from the first invocation, and will not reflect new values. This issue is well documented in the mod_perl guide, along with several remedies for the problem, none of which I like too much.

Looking over that discussion, it occured to me that the 'my $x if 0' construct can resolve this issue:

sub OUTER { my $x if 0; $x = 0; print "OUTER: \$x is now: ", ++$x, $/; sub INNER { print "INNER: \$x is now: ", ++$x, $/; } } OUTER;INNER;INNER; OUTER;INNER;INNER; ## results OUTER: $x is now: 0 INNER: $x is now: 1 INNER: $x is now: 2 OUTER: $x is now: 0 INNER: $x is now: 1 INNER: $x is now: 2
What's happening here is that successive invocations simply overwrite the values bound upon the initial invocation. Since we've cheated Perl out of enacting the run-time effect of my $x, this allows lexical variables to stay shared between outer and inner named subroutines (despite -w's admonitions to the contrary).

I don't think I would do something like this in production code. I'll probably stick to using package globals, perhaps with our-scoping, but it's certainly worth thinking about and perhaps incorporating as a bonified language feature in future perl releases, eg:

... my $fname : static = $q->param('fname'); my $lname : static = $q->param('lname'); ...
   MeowChow                                   
               s aamecha.s a..a\u$&owag.print

Replies are listed 'Best First'.
my $foo if 0; is a bug
by tilly (Archbishop) on Jul 15, 2001 at 04:58 UTC
    You are seeing the bug in a form where it almost makes sense. However it really is a bug. When I first saw this, it was a bug in Number::Format which turned out to be due to a construct of this form:
    my $foo = $some_init unless test();
    The resulting bug is that if the test failed on 2 calls in a row, you had data from the first call of the function that polluted your output results. This bug was quite subtle and mysterious, and it turned out had been reported to the module author several times over the course of a year, but he was unable to figure out where the bug was.

    Since then whenever I have looked at a large body of code for either of the patterns:

    /my .* if/ /my .* unless/
    and found a match, it has usually resulted in also finding a bug. In short, this is a "feature" that is due to a broken optimization of Perl which, when it is hit in code, is almost always the cause of a bug in that code.

    Now if you want static lexical variables without the usual "create a private scope" trick, that is doable in a fairly straightforward manner. In fact I just wrote and tested an implementation, which I just uploaded to CPAN. Hopefully Tie::Static will be accepted and become available shortly. (I intend to post the module to PerlMonks in a short while as well.)

      You make a very good point, and one that I whole-heartedly agree with. As I said, I wouldn't use this sort of thing in real code, but I thought it's worth demonstrating that there are cases where it's quite useful to be able to declare a variable of static lifetime without having to create an enclosing scope. Yes, I see that it can be done with tie, though I usually avoid tied variables after having had a few nasty experiences with their performance. The requisite caller voodoo makes a tied implementation even less appealing.
         MeowChow                                   
                     s aamecha.s a..a\u$&owag.print
Re: It *is* a feature: mod_perl and 'my $x if 0'
by BMaximus (Chaplain) on Jul 16, 2001 at 03:36 UTC
    I tried the code with local; in Unusual Closure Behaviour and got the same results. The variable's contents hung around. I thought our was going away?

    BMaximus