My criteria are based on what I have said before. By those criteria strict is good because it keeps you from accidentally using a variable that you didn't intend to (thereby catching spelling mistakes). my is wonderful because it gives you a way to make private variables guaranteed to be private. After all who cares that my $line may have the same name as another variable when it is guaranteed to be private and limited to 5 lines out of a 10 line function? And finally using vars takes care of the need for making it easy to keep track of shared variables.
So what do we get that we should want with the new keyword? And is it really worthwhile?
Well what it does differently is give us lexically scoped access to a global variable. So it does what vars is for but scoped like my. The idea is so we can share variables and make them limited to just a few functions. Just declare then within the places you need access.
But do I want that?
No. I don't want to have to put that declaration in multiple places. What happens if I get the name wrong in one block? That is an easy error to make (read I catch myself making it quite often) and I like having that caught. So I don't want the unnecessary synchronization. Also when you make it harder for me to find out in one place what all the shared variables I am using are, it is easier for me to get into namespace collisions.
So what is it for? I have been told it is a good way to get variables to be scoped by file. Well since my files tend to match my package declaration, that isn't a need I often feel. But when I do feel it I can use my. And I get the win of having it truly protected.
But, you say, what if I want it file scoped and I need access from two files? Well that synchronization problem I gave above? It is only worse when I have several files. But if I create a module that uses Exporter to export the variables then I can use it in multiple places with a check so that if I get the name wrong anywhere I am told about it. But, you say, I need to now synchronize the use command with the use vars. Right. But I always follow the directions in Exporter and use @EXPORT_OK. I find that I don't often get into synchronization errors between two adjacent lines. I get them between two files or between functions a page or two apart. My brain has lost track and I misname it. But I don't do that when the lines are right next to each other.
And so it goes. The very name, "our", suggests that its purpose is for sharing. But by the way it works if you try to use it for sharing then you leave yourself open for synchronization errors. And you can already accomplish the same tasks without that risk. And if you don't use it for sharing then it does the same thing as other declarations that we have without the incentive to make it easy for someone else learning the code to find out what is already shared because that information has been scattered through the code.
Really, until today I had never thought about it. But now that I have thought about it I don't like it. The more I think about it the less I like this feature. And so I am asking what need it fills that makes it worthwhile. Other than being the cool feature of the day...