Because if I have to type a variable name in two different files, my typo rate is fairly high. Therefore I really, really want to declare it in one file, and let strict.pm catch my typos everywhere else.If that solution won't work, then I will "use vars" for the declaration. I never use our for any variables that I've invented within my code. ...I really don't see why you'd make that distinction. I just use our() for all package variables.
The only time I don't do that is when I'm working with an external API that doesn't give me the option. For example if I were to reinvent Exporter I would seriously think about pre-declaring @EXPORT_OK in the caller's space so that the caller can just access it and will get a useful error for accidentally typing @EXPROT_OK. Were I reinventing it for my own use, then I would definitely do that.
Let me think about it and see if there is any situation where I would use our in my own code. Hmmm.
There is one. And that is for a situation where I want a variable that I only access in one file but I want to use local on it. I'm not sure when that need might come up since it has never yet happened. Of course if Larry would allow local to be used on lexical variables, than that need would go away. (Note, he disallows it because of the potential for confusion, and not for technical difficulty. You can use local in more places than you might think - I like using it on the values of lexically scoped hashes.)
In reply to Re^8: My globals are visable; but undef'ed
by tilly
in thread My globals are visable; but undef'ed
by Wiggins
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |