Loading ...
Sorry, an error occurred while loading the content.

54266Re: PATCH porting.pod "First Mystery"

Expand Messages
  • Stas Bekman
    Sep 2, 2003
      Brian McCauley wrote:
      >>Nice, but:
      >> > +The easiest and the fastest way to solve the nested subroutines
      >> > +problem is to change C<my> to C<local> C<our> for all variables for
      >> > +which you get the warning. The C<handler> subroutines are never
      >> > + local our $counter = 0;
      >>local our? That should be either local or our, but not both.
      > No.
      >>Do I miss something?
      > Yes. (I tried to explain this in Paris but I was in danger of causing
      > you to miss lunch completely).
      > local() and our() do two quite separate and complementary things.
      > our() (in effect) declares a lexically scoped alias for a package
      > variable.
      > local() restores the old value of a package variable (usually undef)
      > at the end of the current lexical scope.

      In effect you use local() to undef the variable, instead of explicitly
      initializing it. Why not doing this explictly?

      so instead of replacing:

      my $counter;


      local our $counter;

      it's probably better to say:

      our $counter = 0;

      or if you insist on using both:

      our $counter;
      local $counter; # undef $counter

      later on I show why this is better for user's understanding.

      > The two combined therefore give a package variable two of the most
      > useful properties of a lexical one. Of course a real lexical variable
      > doesn't really become undefined when it does out of scope - it really
      > becomes anonymous, and iff there are no remaining (unweakened)
      > references it then gets GCed. But for file-scoped lexicals in the
      > main script file the difference is usually not that important. Both
      > effectively get killed at the point where global destruction would
      > have taken place.
      >>The rest looks good, but that's not the simplest solution as you have
      >>to modify the variables.
      > Is there a simpler one? For a typical script with say half a dozen
      > variables the "would not remain shared" the "local our" solution
      > requires a dozen keystokes on each of half a dozen lines.

      Don't forget that our() is not available before perl 5.6. So we can't quite
      eliminate the previous solution unless you suggest to go with a
      back-compatible version:

      use vars qw($counter);
      local $counter;

      and of course the proper solution is:

      use vars qw($counter);
      $counter = 0; # or undef

      which is documented in the perl reference section.

      >>Granted, the original "simplest" solution has its troubles.
      > The original "simplest" solution involved finding (and subsequently
      > maintaining) a globally unique filename then splitting the program in
      > to two parts. Thereafer you have to maintain two files even on CGI
      > servers. I would contend that this "simple solution" is not simple.
      > If you are going to all that troble you may as well to the extra
      > 804.65m and produce a proper mod_perl handler and a small wrapper to
      > make it work also in a CGI environment. Also, as of mod_perl2, the
      > "simple solution" is not even, as it stands, a solution as it relied
      > on the script being in the CWD.

      Remember, we are talking about mp1 guide patching. Not everything that applies
      to mp1 applies to mp2. e.g., mp2 requires 5.6+, so we indeed can rely on using
      our() there. And I hope that the problem with CWD will be resolved once Arthur
      will fix that.

      If you think that using globals + their initialization is a better solution,
      which will work well in mp1 and mp2, we can replace the lib.pl solution with
      it, but should add it to the perl reference section.

      Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
      http://stason.org/ mod_perl Guide ---> http://perl.apache.org
      mailto:stas@... http://use.perl.org http://apacheweek.com
      http://modperlbook.org http://apache.org http://ticketmaster.com

      Reporting bugs: http://perl.apache.org/bugs/
      Mail list info: http://perl.apache.org/maillist/modperl.html
    • Show all 20 messages in this topic