Stas Bekman <[EMAIL PROTECTED]> writes:[...]
[...] 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.
I assume that was a typo :-) s/declare/initialize/.
Yes, thank you!
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.
I don't. On the contrary I explain the importance in the narrative and also re-enforce the importance in comments in the example code. I have, at your suggestion, pushed into an afterthought any mention of the fact that if you need to use local() anyhow you can get away without explicit initialization of package variables.
Since it appears you _are_ against mentioning it even at the end I'll remove it completely from porting.pod. I don't care, I'm not on a crusade here.
Unless you are an advanced user and know what you are doing, it's a goodness to always initialize variables before you use them.
Of course I agree that initializing variables before you use them is good. It's just that I think that implicit initialization using my() or (if you can't use my(), local()) is better than explicit initialization using undef(). IMNSHO, whenever one sees an explicit ``$var = undef'' or ``undef($var)'' an alarm bell should ring and ones first thought should be "is there a missing/misplaced my()/local()?".
When did I say that initializing to undef is good thing? I was talking about initializing variables to the types there are going to use, e.g.:
my $counter = 0; # numbers my $string = ''; # strings
BUT....
I can't see why we are still arguing about this. I've worded the document _as_if_ I agreed with you that explicit initialization was a "good thing" per se. The fact that we disagree is, therefore, surely, irrelevant.
Most likely we both try to say the same thing, but misunderstanding each other...
+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.
Yes, that does read more easily. But the dangling "for" now grates. Particularly the juxtaposition "for to". So I'd keep the "for which" even if some people consider such strict English grammar to be affected.
I guess it reads better if using commas:
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.
I would drop the word "global" since global has many different meanings. By one definition of "global", the orginal file-scoped lexical variable was global. By another definition of "global", package variables (other than ones like %INC) are not global.
The use of the phrase "global variable" in Perl documentation as a synonym for "package variable" is AFAIK deprocated.
Some people use the phase "global package variable" (or "global global variable" (sic)) to refer to a variable like %INC.
I've even seen examples where people use the phrase "global variable" to mean "package variable in package main".
Well, the problem I have with this approach is the following: I think of lexical variables as non-accessible from outside the scope thy exist in. This is incorrect for variables declared with 'our' and 'use vars', since those variables are accessible outside the file/package they were defined in. Which makes them non-lexical. No?
or something like that?
OK:
The easiest and the fastest way to solve the nested subroutines problem is to switch every lexically scoped variable for which you get the warning to a package variable.
sounds good.
package scope is lexical scope too.
Er, now I'm really confused. The our() function declares a lexically scoped alias for a package variable - but this is getting far too subtle.
See my comment above.
+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 +su bsequent 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.
Again I dislike the word "global" for reasons already stated.
I think it would read better if we use consistant terminology. EITHER "not necessary" v "necessary" OR "redundant" v "not redundant" but NOT "not necessary" v "not redundant".
Agreed.
+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?
Er, lexical v _package_
OK
__________________________________________________________________ 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
