I first questioned its utility in Why is 'our' good?. There are four basic problems that I know of with it. (I'm not counting the silly one that I pointed out above.)
- You have 2 packages in one file and didn't intend to use the variable from one package in the code for the other. This should be uncommon but not that uncommon.
- You have 2 files that access one package and you introduce synchronization issues. This is rarer than the first.
- A developer mistakenly tries to use our like you should use my. Now you have lots of room for a typo causing the variable accessed in one place to be different than the one in another, and strict.pm doesn't help.
- Using our is a gratuitous portability problem for people on Perl 5.005_05. Back when I first thought about this issue, that was a much bigger deal than it is today.
Its only advantage (in Perl 5) is that it involves slightly less typing. So while I consider it distinctly worse, it isn't really THAT bad.
As Larry pointed out in response to my node, its real purpose was a place to hang declarations about the variable in scope. For instance I believe one can say things like our Dog $spot is constant; and that has told Perl 6 that $spot must be something of type Dog, and in this lexical scope we are not allowed to change $spot. That's all functionality that couldn't be done with the old declaration. | [reply]
[d/l] |
The file-scoping is annoying I guess, but sort of in line with lexical scoping rules. And I haven't used perl 5.005 in ages.
You have 2 files that access one package and you introduce synchronization issues.
How does that happen? I though our() just made package variables available without too much fuss.
| [reply] |
You say "package Foo" in two different files. :-)
As I said, this should be very rare. But sometimes you want to add or modify functionality in a package someone else wrote. (I've done this several times in Ruby where I'm changing core classes.)
However there is a more common variation of the same thing. If you take a module and refactor it by using AutoLoader, then our variables are not visible in the autoloaded subroutines, but use vars would be.
| [reply] |