Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
Syntactic Confectionery Delight
 
PerlMonks  

Why is 'our' good?

by tilly (Archbishop)
on Dec 27, 2000 at 08:31 UTC ( #48379=perlmeditation: print w/ replies, xml ) Need Help??

With 5.6 Perl introduced a new keyword, the latest and greatest scoping mechanism, our. I happen to understand exactly what it does and I believe I understand what it is for. But having just had the topic come up today, I am currently not convinced that it is actually better than what it replaces.

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...

Comment on Why is 'our' good?
Re: Why is 'our' good?
by autark (Friar) on Dec 27, 2000 at 12:47 UTC
    I'm not going to argue for or against the our keyword. But this is how the creator envisioned it.

    Autark.

      It is an excellent explanation of what it actually does. I am still going through the discussion. The best use of it is described in this, but as Tom Christiansen says, if you want to actually be sharing stuff, then vars does a better job. Besides which, our doesn't do a better job of helping the programmer know which globals are special. So yes, our @ISA = 'Exporter'; may make sense. But the programmer is just leaving a reminder of something that is hopefully known - @ISA is special and shouldn't be used as an array.

      Incidentally here someone asks about whether "our $_" has any use. Larry didn't see one. However some of the obfuscators out there might find it useful to combine the features of our with the fact that some variables are supposed to be in package main:

      package Foo; our $_ = "Hello\n"; print $_ for 1..5;
      Of course when someone who doesn't like obfuscation starts looking at a new feature and talking about the obfuscation possibilities, that is not the best of signs.

      So the fact that Larry doesn't like use vars and would like to replace it is fine by me. But I don't think that our is a better replacement. Yes, I think that he did a good job of producing the language. But he still saw fit to add reset, he is human and I reserve the right to my opinion...

Re: Why is 'our' good?
by Dominus (Parson) on Mar 30, 2001 at 19:08 UTC
    The other big problem with our() is that it is advertised as a replacement for use vars:
    NOTE: The functionality provided by this pragma has been superseded by our declarations, available in Perl v5.6.0 or later. See the our entry in the perlfunc manpage.
    But there are several things that vars does that our() doesn't do. The benefit, as you point out, is a very limited gain of functionality, and the cost is that there is yet one more subtly different feature complicating Perl's byzantine scoping and namespace rules.

Re: Why is 'our' good?
by TimToady (Parson) on Sep 24, 2004 at 21:16 UTC
    Something that seems to be missed every time this discussion is referenced is that the main purpose of our is not to replace use vars, but to serve as a syntactic peg upon which lexically scoped traits can be hung. The purpose of our is to provide a lexically scoped view of a global variable. The variable itself might not be constant, for instance, but I might want to declare it that way for the sake of my own discipline. Beyond that, various forms of allomorphism will only get more important as Perl 6 allows more type and trait declarations within variable and subroutine declarations. But even leaving allomorphism out of it, traits are becoming much more important in Perl 6. For instance, exported variables in Perl 6 are simply marked with an "is export" trait rather having to duplicate their names in an @EXPORT_OK list somewhere.

    The secondary reason for having a lexically scoped declaration is to limit your exposure to accidental use of the variable. But really, that's just another aspect of controlling the "view", or non-view, in this case.

    I doubt we'll all ever see eye-to-eye on the subject of globals, but at least grant me the privilege of pointing out that, at least in my mind, the feature was added more to future-proof the declaration syntax than out of reaction to use vars. I freely admit that our is of marginal benefit in Perl 5, but I was already thinking ahead to Perl 6 at that point, even if Perl 6 hadn't been named yet. :-)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://48379]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (4)
As of 2014-04-18 11:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (466 votes), past polls