54913Re: PATCH porting.pod "First Mystery"
- Oct 14, 2003Brian McCauley wrote:
> Stas Bekman <stas@...> writes:I'm not disagreeing with you on this. But I will wait for your second patch
>>- 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.
and commit both at once otherwise one of the solutions gets temporary lost...
>>- suggest turning a lexical variable declared with my() into a globalIt's not really mine, I just happen to maintain it. From the previous
>>variable declared with our() to avoid the closure, with the following
>> 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
> 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.
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 (inFrankly, I can't understand why do you try to undermine the importance of
> particular 'use vars') into comments inside the code examples where
> they can be expressed more concisely.
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 subroutinesWould it be better to say:
> +problem is to switch from lexical scope to package scope for all
> +variables for which you get the warning. The C<handler> subroutines
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.may I suggest the following wording:
> +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.
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 ofshared variable? Can we stick to lexical vs. global, and not confuse user even
further? shared variables are special with ithreads and allow sharing data
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: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 >>