And here I was under the impression that my pointing out the trick was a comment.. :-D
Seriously now, you're right that it does make that section of the code depend on position. Which I don't see as a horrible thing - no worse than a lexically scoped variable. And certainly not in boilerplate initialization code which many people who use it won't expect to understand.
If you're uncomfortable with that fact you can always declare the variables as is usually done. In fact I pointed out that I'd done it so that people could make that choice.
Also I deliberately didn't comment on the mechanics. If I thought that the mechanics required commenting on within the code, then I'd first try to solve that by changing the mechanics, not commenting the code. | [reply] |
My thinking that a comment in the boiler plate code would be appropriate as once code gets into a module, those coming along after may not appreciate it's source or significance.
Avoiding globals all together would be the best route, but that's not currently possible for the likes of these "special variables".
For a long time I didn't really appreciate your concerns regarding our, but having quite recently been bitten by a typo in an our var, they can indeed cause mysterious problems.
I guess what I would really like, whilst doing away with globals completely is not an option, would be a combination of the two; use vars; and our.
The former would indicate those globals I intended to use and disable the warnings/strictures on them--but only within those scopes where I had used our for that same variable.
Using our for a var that hadn't previously been declared with use vars would raise an error. As would attempting to use a global mentioned in use vars, without also having scoped it using our.
I'm not really a S&M type, and that does sound like "belt & braces" even to me, but given my propensity for typos, and the number of saves that "Global symbol "$x" requires explicit package name.." makes on my behalf, I would welcome this ability.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
| [reply]
[d/l]
[select] |
package Some::Package;
use vars qw/test/;
sub inHere {
our $test;
}
If so I think that would be far more intuitive than the current setup. After a year of perl I still have no concept of our.
| [reply]
[d/l]
[select] |
# Would warn if Data::Dumper used 'our' instead of 'use vars'.
local $Data::Dumper::Useqq = 1;
Your idea would reverse the purpose of use vars. Instead of allowing a variable to be used outside the module, it would prevent the variable from being used outside the module.
The underlying idea is good, but you'd need to use something other than use vars. | [reply]
[d/l]
[select] |
| [reply] |