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

54251Re: PATCH porting.pod "First Mystery"

Expand Messages
  • Brian McCauley
    Sep 1, 2003
      Stas Bekman <stas@...> writes:

      > nobull@... wrote:
      > > In private mail Stas Bekman <stas@...> writes:
      > >
      > >>oops, that should be the modperl list... at modperl-docs we discuss
      > >>mostly site/docs techical issues and there are very few people on this
      > >>list to get enough exposure for this kind of feedback request.
      > > Patch for "The First Mystery" section of the mod_perl porting guide
      > > as
      > > per my conversation with Stas at YAPC::Europe::2003.
      > > Takes out the suggestion of creating a Perl4-style library in the
      > > same
      > > directory as a means to port CGI scripts.
      > > Replaces it with something simpler and more reliable.
      > 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.


      > 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

      local() restores the old value of a package variable (usually undef)
      at the end of the current lexical scope.

      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.

      > 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.

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