54251Re: PATCH porting.pod "First Mystery"
- Sep 1, 2003Stas Bekman <stas@...> writes:
> nobull@... wrote:No.
> > 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 haveIs there a simpler one? For a typical script with say half a dozen
> to modify the variables.
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
- << Previous post in topic Next post in topic >>