Win32 EXPORT_OK problems

[InfiniteSilence]

Ok, I am using Activeperl on a Win2000 box and I am running into a problem with the following module:

BEGIN {
    use Exporter;
    my ($VERSION,@ISA, @EXPORT_OK, %EXPORT_TAGS);
    @ISA = qw(Exporter);
    %EXPORT_TAGS = ();
    @EXPORT_OK = qw(&IPGrab);
    $VERSION = 0.02;
}

sub IPGrab
{
  print "\nfoo";    
}

When I try and use this, as follows:

#!/usr/bin/perl -w
use strict;
use hits qw(:IPGrab); 
&IPGrab();

I get the following error message:

Undefined subroutine &main::IPGrab ....

Any ideas as to why as to why the function &IPGrab doesn't make it into my namespace?

Celebrate Intellectual Diversity

[chipmunk]

$VERSION, @ISA, @EXPORT, etc. must all be package variables. You have declared them as lexical variables instead, which means that as far as Exporter et al. are concerned, they don't exist. (In fact, since they're lexicalized to the BEGIN block, they don't exist for the rest of your module either.) This is why all the examples show use vars qw/@EXPORT @EXPORT_OK .../; instead.

Note also that you want to import qw(IPGrab), rather than qw(:IPGrab), because you don't have an :IPGrab export tag.

[InfiniteSilence]

I fixed the code, but by using the format found in original permod documentation here. The format use vars() complained that my variables required explicit package names. Further research into use vars() tells me that it is 'obsolete' as of 5.6.0!!! Our is apparently the suggested, current, usage anyway.

Celebrate Intellectual Diversity

[merlyn]

It's only the current suggested usage if you're able to move past 5.5.3. Many sites aren't, and are patiently waiting for 5.6.1. There's nothing "obsolete" about "use vars"!! It'll continue to work long until 5.8 is out. :)

-- Randal L. Schwartz, Perl hacker

[chipmunk]

I presume you got an error with use vars because you had: use vars (@ISA @EXPORT @EXPORT_OK); instead of: use vars qw(@ISA @EXPORT @EXPORT_OK); In the former, you are referring to variables that you have not declared yet. In the latter, you have a list of strings, each one of which happens to be the name of a variable. Examples in the documentation show the proper way to use vars: vars, strict

[InfiniteSilence]

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

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

Celebrate Intellectual Diversity

[tye]

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.

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

[tilly]

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.

Try the following sample script:

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

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.