Stas Bekman <[EMAIL PROTECTED]> writes:
- move the perl4 lib solution to the perl_reference.pod
Will do when I get round to that bit. I still think a mention of it is needed in porting.pod to warn people away from it. If you disagree simply delete the offending paragraph.
I'm not disagreeing with you on this. But I will wait for your second patch and commit both at once otherwise one of the solutions gets temporary lost...
- suggest turning a lexical variable declared with my() into a global variable declared with our() to avoid the closure, with the following "but"s:
o if with my() it wasn't crucial to initialize the variables (since my() initialized them to 'undef'), now all variables declared with our() must be explicitly initialized.
[Brian: notice that I prefer *not* to suggest using local() to init vars, and rather have users do that explicitly, which is a good practice]
Well I disagree with you about it being good a practice. I personally consider it good practice to work in a way that minimises the number of things you have to do explicitly (with the exception of declarations). I can't see why you think relying on the fact that local() will initialize variables to undef is any worse than relying on the fact that my() will.
But this is your document so I shall go along with your preferences.
It's not really mine, I just happen to maintain it. From the previous discussion it seems that those who cared agreed that it's better to explicitly declare vars. Granted 'local our' works, but for (most?) users this point will be lost, as they will just copy-n-paste examples without understanding why is it so. Power users can figure it out on their own, and I wasn't against mentioning it at the end after explaining the longer (more explicit?) solution. I think that makes it a happy compromise, no?
I've tried to keep it brief by moving some of the points (in particular 'use vars') into comments inside the code examples where they can be expressed more concisely.
Frankly, I can't understand why do you try to undermine the importance of always initializing variables. Please remember that this docs is used as a reference by users of varying expertise in Perl. Unless you are an advanced user and know what you are doing, it's a goodness to always initialize variables before you use them.
+The easiest and the fastest way to solve the nested subroutines +problem is to switch from lexical scope to package scope for all +variables for which you get the warning. The C<handler> subroutines
Would it be better to say:
The easiest and the fastest way to solve the nested subroutines
problem is to switch every lexically scoped variable you get the warning for to a global package variable.
or something like that? package scope is lexical scope too.
+are never called re-entrantly and each resides in a package to itself. +Most of the usual disadvantates of package scoped variables are, +therefore, not a concern. Note, however, that whereas explicit +initialization is often redundant for lexical variables it is usually +not redundant for these package variables as they are reused in +subsequent executions of the handler.
may I suggest the following wording:
Note, however, that whereas explicit
initialization is not always necessary for lexical variables it is usually
not redundant for these global package variables as they persist in
subsequent executions of the handler and unlike lexical variables, don't get automatically destroyed at the end of each handler.
+If the shared variable contains a reference it my hold onto lots of
shared variable? Can we stick to lexical vs. global, and not confuse user even further? shared variables are special with ithreads and allow sharing data across threads.
also s/my/may/
The rest looks good. Thanks Brian.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
