54931Re: PATCH porting.pod "First Mystery"
- Oct 15, 2003Brian McCauley wrote:
> Stas Bekman <stas@...> writes:[...]
>>>[...] this is your document so I shall go along with your preferences.Yes, thank you!
>>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/.
>>>I've tried to keep it brief by moving some of the points (inWhen did I say that initializing to undef is good thing? I was talking about
>>>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()?".
initializing variables to the types there are going to use, e.g.:
my $counter = 0; # numbers
my $string = ''; # strings
> BUT....Most likely we both try to say the same thing, but misunderstanding each other...
> 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,
>>>+The easiest and the fastest way to solve the nested subroutinesI guess it reads better if using commas:
>>>+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
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 differentWell, the problem I have with this approach is the following: I think of
> 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".
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?sounds good.
> 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.
>>package scope is lexical scope too.See my comment above.
> 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.
>>>+are never called re-entrantly and each resides in a package to itself.Agreed.
>>>+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".
>>>+If the shared variable contains a reference it my hold onto lots ofOK
>>shared variable? Can we stick to lexical vs. global, and not confuse
>>user even further?
> Er, lexical v _package_
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
- << Previous post in topic Next post in topic >>