Stas Bekman <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > In private mail Stas Bekman <[EMAIL PROTECTED]> 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.
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. 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
