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

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.

Replies are listed 'Best First'.
Re^17: the "our" declaration ?!! (special vars)
by Anonymous Monk on Jan 22, 2009 at 07:21 UTC
    use vars::i qw[ @EXPORT_OK  foo ]; vars::i
[reply]
[d/l]
Re^17: the "our" declaration ?!! (special vars)
by LanX (Saint) on Jan 22, 2009 at 13:09 UTC

    first example:

    OK, you want extend a singular declaration for a package to multiple files. That's handy when you want to split a big package into multiple files, but you can achieve this with "require" and "do". 

     
#--- subfile
my $file="our_reg.pm";
print "$file: $x";

    [download]
    #--- basefile
use strict;

my $file="our_base.pl";
$\="\n";

package one;
our $x=__PACKAGE__;

print "$file $x";

require our_req;

package two;
our $x=__PACKAGE__;

print "$file $x";

do "our_req.pm";

    [download]
    #--- OUTPUT
/usr/bin/perl -w /home/lanx/perl/pm/declare/our_base.pl 
our_base.pl one
our_reg.pm: one
our_base.pl two
our_reg.pm: two

    [download]
    for most other cases I can think of, it's IMHO better to use getter and setters for packvars, if you don't want to repeat the "our"-declaration.

    second example:

    Right,,in contrast to "our" the scope of "vars" is bound to "package". That's why one should use curlies around multiple packages, to clarify the scopes!!!

    That's exactly my point, you can use "our" like "my", without getting confused about different scoping rules...

    Cheers Rolf

    UPDATES:

    Let's sum it up, TIMTOWTDI, and you prefere saving code with the one variant and prefere saving some lines with the other .. ; )

    well how is it done in perl6???

[reply]
[d/l]
[select]
      I never said that you can't use our for the same task. I said that it was worse.

      In example 1, with our it is a lot easier to make and a lot harder to catch a mistake where in one file you have declared $with_foo while in the other you've named it $for_foo. This makes our worse.

      In the second example, to avoid problems you are requiring people to have a habit that most people don't have. Furthermore it is not enough to put curlies around your package declarations, you also have to put curlies around your original program. However taking that step means that if you discover that you need a small auxiliary package, you have to make a much, much bigger change. Again our is worse.

      Summary: from a software engineering standpoint, in Perl 5 our is the same or worse than vars. Its only win is a slight convenience/aesthetic advantage.

      (My attitude is that Perl 6, if it ever arrives in production, will be a different language that needs to be judged on its principles.)

[reply]

In Section Seekers of Perl Wisdom