in reply to Re^12: the "our" declaration ?!! (special vars)
in thread the "our" declaration ?!!

The real benefit of "our" is that it's block scoped. It's not "I know about this variable in the current package, let me access it directly wherever I am". It's rather "Excuse me? I'd like to access this 'global' variable over here without having to prepend the package name." Its effects are much more restricted (OK, this depends on the location of the "our" declaration). So you specifically CAN'T declare something in one file and have it affect the code in another, you can't declare somewhere that you intend to use a 'global' variable and silence all fatal errors for such named variables all over the place no matter whether on that other place you are aware of some global.

Of course if you declare all your globals on top of the file it doesn't matter much whether you use vars ... or our (...). But that's about as clever as declaring all variables with my (...) on top of the file. You can, but you should not.

I would rather our in this block and our in that block and stay "safe" elsewhere.

Jenda
Support Denmark!
Defend the free world!

Replies are listed 'Best First'.
Re^14: the "our" declaration ?!! (special vars)
by tilly (Archbishop) on Jan 21, 2009 at 23:38 UTC
    When I our in this block and our in that block, nothing prevents me from accidentally using slightly different variable names in the two blocks. This is a common error for me, particularly when the blocks are far apart, and I really want strict to catch it.

    Therefore if I want to access a global in 2 places, I really, really want to declare that global in one place. While the ability to declare it in multiple tight scopes sounds neat, it is bad software design to do things that way.

[reply]
[d/l]
[select]
      As Jenda pointed out you can still declare once with our() on top of the file, which has the same effect as "use vars"...

      Sorry, I still don't understand what you can do with "vars" which is not possible with our()¹. Could you please post a short code example to make it clearer?

      UPDATES:
      (¹) Or an explicit import() method.

[reply]
        Here are two examples of things that vars does differently and better than our.

        First let's assume you haven't seen the light of packages and use Library.pm: 

        use strict;
use vars qw($foo);
# ... code that uses $foo ...
1;

        [download]
        And then you have script.pl 
        use strict;
use Library;
# You can now use $foo freely.

        [download]
        The other example goes like this: 
        use vars qw($foo);
# Some code here.

package Bar;
# Now you can't use $foo, and won't accidentally access $main::foo.

        [download]
        Both examples are admittedly trivial. But in both cases what vars does is better than what our would do.

        Now where is the win with using our? It is that it lets people write this: 

        package Foo;
use strict;
use Exporter qw(import);
our @EXPORT_OK = qw(foo);
# etc
1;

        [download]
        instead of the 1 line longer 
        package Foo;
use strict;
use Exporter qw(import);
use vars qw(@EXPORT_OK);
@EXPORT_OK = qw(foo);
# etc
1;

        [download]
        or the (to many people) less aesthetic 
        package Foo;
use Exporter qw(import);
@EXPORT_OK = qw(foo);
use strict;
# etc
1;

        [download]
        This win does not, in my eyes, qualify as important enough to make our be a major improvement in Perl. Nor does it make it a significant improvement on vars.

        That said, Larry Wall's thinking is that our was a declaration on which he could hang other syntax. Yes, this is the famous "my Dog $spot" discussion. That hasn't happened in Perl 5, nor does it seem likely to in the near future, but it is supposed to in Perl 6. At which point our would have substantially greater functionality. But that hasn't happened yet.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom