Stas Bekman <[EMAIL PROTECTED]> writes:
Brian McCauley wrote:
Here's a _very_ rough first cut at perl_reference.pod. I haven't even proof-read it yet so it's probably got spelling a and grammar errors but I just want to be sure I'm going in the right direction.
Thanks Brian. A few comments:
[...]
- #!/usr/bin/perl -w + #!/usr/bin/perl use strict; + use warnings;
But that won't work with perl < 5.6.
This is example code being used to illustrate a point. It is more appropriate therefore (IMHO) that it reflect best current practice than that it maintain backward compatability. Anyone still using Perl < 5.6 must be used to seeing "use warnings" all over the place and know that they need to remove it on their system. Unless, of course, they are living in total isolation - in which case they'll never see this document so the point is moot anyhow.
Agreed.
+The simplest of the workarounds is to use package-scoped variables, +declared using C<our> or, on older versions of Perl, the C<vars> +pragma. Note that whereas using C<my> declaration also implicitly +initializes variables to undefined the C<our> declaration does not, +and so you may need to add explicit initialisation. multirun1.pl - ----------- - #!/usr/bin/perl -w + ------------ + #!/usr/bin/perl use strict; - use vars qw($counter); - + use warnings; + for (1..3){ print "run: [time $_]\n"; run(); @@ -946,7 +953,7 @@ sub run { - $counter = 0; + our $counter = 0;
I think it would be more clear if all are declared at the top of the file,
Declaring variables at the top of the file is, IMNSHO, a bad programming habit that should be discouraged. Variables' declaration and initialisation should be kept together wherever possible. It seems more natural. It aids readibility. It aids maintainability. I have collegues who program in the "declarations go at the top" style. Their programs almost invariably declare variables that are never then used.
Sorry I've missed the word "globals" while typing, so it should have read:
I think it would be more clear if all globals are declared at the top of the file,
You are talking about the locality rule, which I perfectly agree with when it comes to scoped variables.
However when it comes to globals I tend to disagree with you. globals should be all declared together at the top of the file/package so that it's easy to learn what variables are globals and not scan the code (perhaps thousands of lines trying to spot those globals definition in the code where they are used.
Consider:
% perl -le ' {our $x = 5;} print $x'
5Now move that our definition hundreds of lines into the code, are going to spot it?
Granted, using 'use strict':
% perl -le ' use strict; use warnings; {our $x = 5;} print $x'
Variable "$x" is not imported at -e line 1.
Global symbol "$x" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.this potential error of our() scoped variable affecting some other global with the same name, won't creep in. But unfortunately many don't use 'use strict'.
Of course you will say that the example does use 'use strict' and therefore this global definition is scoped well and defined where it should be. And you'd be right. In which case I've no objections.
/me is still trying to wrap his head around our()'s subtleties.
just where the 'use vars' declaration was.
Remember that you are looking at the diff file so it seems to you that I've moved the declaration. The end-user reader of perl_reference.pod is not looking at the diff file. They are comparing multirun.pl and multirun1.pl. So from their point of view, by simply replacing "my" with "our" I'm keeping the declaration in the same place. If we were to move the declaration away from the initialisation then I think we'd have to explain why we did it. And since I think it's a bad idea I couldn't do that.
Agreed.
[...]
multirun2.pl - ----------- + ------------ #!/usr/bin/perl -w use strict; @@ -993,14 +1023,14 @@ sub run { - $main::counter = 0; + $::counter = 0;
what's the gain in doing this? The two are identical and for unexperienced perl users $::counter will look totally alien.
That, of course, would depend on the nature of their (in)experience to date :-). If they have always seen explicit access to variables in the root namepace written as $::counter then it is the use of the alias $main::counter that will look totally alien.
I guess I have hardly ever seen code that uses $::, and still strikes me odd. But that's just my personal (in)experience as you put it.
However, given that I go on to refer to root namespace as 'main::' later on, I suppose it makes sense to be consistant and revert to using the alias throughout.
Perfect.
The rest looks good, sans spelling ;)
I'll try to fix that now.
Combined patch follows.
Perfect. Both are now committed and will appear online within the next 6 hours.
Thanks a lot, Brian. Please keep those patches coming (and I promise to be build less walls next time).
__________________________________________________________________ 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
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
