54266Re: PATCH porting.pod "First Mystery"
- Sep 2, 2003Brian McCauley wrote:
>>Nice, but:In effect you use local() to undef the variable, instead of explicitly
>> > +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.
initializing it. Why not doing this explictly?
so instead of replacing:
local our $counter;
it's probably better to say:
our $counter = 0;
or if you insist on using both:
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 mostDon't forget that our() is not available before perl 5.6. So we can't quite
> 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.
eliminate the previous solution unless you suggest to go with a
use vars qw($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.Remember, we are talking about mp1 guide patching. Not everything that applies
> 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.
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
- << Previous post in topic Next post in topic >>