-- Randal L. Schwartz, Perl hacker

Aha! You were on the right track with your post. There was something wrong with my qw, but I hadn't omitted it, I had accidentally put commas between the names,like so:

use vars qw(@ISA, @EXPORT_OK, ....
[download]

Which also caused the curious message: "Possible attempt to separate words with commas..."

Celebrate Intellectual Diversity

There is no reason for use vars to ever be removed nor for you to stop using it. our offers some slight efficiency improvements, so if you are never going to be using pre-5.6 versions of Perl, then go ahead and use it.

It would be very stupid for the Perl developers to remove use vars since there would then be no good way to make portable modules. Go ahead, try to write a module that uses our if available but then falls back to use vars otherwise. The falling back is easy, but conditionally using our is pretty much impossible (at least right now).

The somewhat strong wording about use vars being obsoleted is unfortunate and probably should be changed.

What is wrong with:

package Our;
require strict; # Must be sure it has been loaded

sub import {
  if ($] < 5.006) {
    my $pkg = caller();
    *{"$pkg\::our"} = \*our;
    @_ = qw(strict vars);
    goto &strict::unimport;
  }
}

sub our {
}

1;
__END__
=head1 NAME

Our - pragma to gracefully degrade 'our' on older Perl's.

=head1 SYNOPSIS

  use strict;
  use Our;    # Must appear after strict
  our($foo);

=head1 DESCRIPTION

On older versions of Perl this undoes strict vars, and imports an
our function.  This allows modules to be developed on newer Perl's
using 'our' yet still run on older installations.

=head1 BUGS

This provides backwards but not forwards compatibility.  Caveat
developer.
[download]

Try the following sample script:

use strict;
use Our;
our ($foo);
$foo = "hello\n";
print $foo;
[download]

OK, so you have to put the Our after the strict. And to get the benefit from strict you need to be doing your development on a recent version of Perl. But this lets you get all of the development benefits of our while still retaining backwards compatibility.

There is a neat "feature" I was missing. The following code does something interesting:

use strict;
package Foo;
our $foo = "Hello world\n";

package Foo::Bar;
print $foo;

package Foo::Baz;
print $foo;
[download]

While the small module I supplied solves the main backwards compatibility issue, there is no way to tie out older Perl's to such (ab)use.

I would still recommend use vars over this.

First, I don't like the idea of a module that rather sneakilly sometimes turns off use strict "vars". If your development moves to a pre-5.6 version of Perl, you could easily not notice that your innocuous use Our has now disabled your use strict.pm until you waste a couple of days chasing the kind of bug that use strict.pm makes obvious (the reason you are supposed to use strict.pm).

I certainly don't consider this risk worth the very minor speed improvement which is the only advantage to our over use vars.

Also, if you are supporting pre-5.6 versions of Perl, you will be testing with pre-5.6 which may require some development in pre-5.6 versions which you shouldn't be doing without use strict.pm.

So my problems with this approach are quite small but I consider them huge compared to the tiny, tiny "problem" that they solve -- being able to use our instead of use vars. If you are firmly into 5.6-and-later Perl and choose to use our, then these provide a nice way to be pollite to people who aren't.

I will continue to do use vars until Perl supports non-blocked compile-time code (or another soltution) for being able to conditionally use our (or until pre-5.6 Perl becomes old enough that I never run into it anymore).

        - tye (but my friends call me "Tye")