Re: Re(7): Usage of our

Whoops! Just when I thought I was getting past the newbie stage, something like this comes along. As they say in the film This Is Spinal Tap, "it is a fine line between clever and stupid."

Yes, the Require Exporter statement is superfluous. The code works or breaks the same with or without it.

Yes, changing the variable name from $a to $aa in the Exporter example breaks the program. (Who would have thought it?)

And yes, using my() in the package MyPack indeed renders the lexical variable invisible outside of the package. What does work, surprisingly to me, is the following:

#tempo2.pl
use strict;
use MyPack;
my $myString = $MyPack::aa;
print $myString;
[download]

and

#MyPack.pm
package MyPack;
use strict;
$MyPack::aa = "Read from Mypack"
[download]

Which only goes to show that a global package variable is, well, global—it is visible by default when called using the name of its package.

The Exporter module, then, must be for some other purpose entirely besides making variables global.

A few simple concepts: scope, packages. How does it get to be so complicated to us newbies?

Update: After R(ing)TFM, I realize that Exporter can export the namespace of package variables outside of that package. However, I was not calling it properly; I was not giving it anything to export.

Comment on Re: Re(7): Usage of our Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re(7): Usage of our by danger (Priest) on May 21, 2001 at 23:22 UTC
The Exporter module doesn't 'make things global', it gives you an easy way to export package variables and identifiers into the calling program -- the calling program may then use them directly (without qualification): `# calling program: foo.pl #!/usr/bin/perl -w use strict; use MyPack; print "$foo\n"; bar(); __END__ # module file: MyPack.pm package MyPack; require Exporter; @ISA = qw/Exporter/; @EXPORT = qw/$foo bar/; use strict; $MyPack::foo = 42; sub bar { print "This is MyPack::bar, who's calling please?\n"; } 1; __END__ # example run: [jandrew:~]$ perl foo.pl 42 This is MyPack::bar, who's calling please?` [download] So, Exporter is used to export things into the caller's namespace. Any package thingy in the package is always available to the caller if fully qualified. You may decide not to export anything (or only a few things) so as not to pollute the caller's namespace, or you may decide to export on demand (by using the `@EXPORT_OK` array instead) rather than exporting by default as the above example does (export on demand is often the better choice, so the caller gets to choose what to import into its namespace). Had I used the `@EXPORT_OK` array instead, then my calling program could have said: `use MyPack qw/bar/;`, and only the bar() routine would have been imported into its namespace (but the caller could still access `$MyPack::foo`).	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Re(7): Usage of our
by danger (Priest) on May 21, 2001 at 23:22 UTC

The Exporter module doesn't 'make things global', it gives you an easy way to export package variables and identifiers into the calling program -- the calling program may then use them directly (without qualification):

# calling program: foo.pl
#!/usr/bin/perl -w
use strict;
use MyPack;
print "$foo\n";
bar();
__END__


# module file: MyPack.pm
package MyPack;
require Exporter;
@ISA    = qw/Exporter/;
@EXPORT = qw/$foo bar/;
use strict;

$MyPack::foo = 42;
sub bar {
    print "This is MyPack::bar, who's calling please?\n";
}
1;
__END__


# example run:
[jandrew:~]$ perl foo.pl 
42
This is MyPack::bar, who's calling please?
[download]

So, Exporter is used to export things into the caller's namespace. Any package thingy in the package is always available to the caller if fully qualified. You may decide not to export anything (or only a few things) so as not to pollute the caller's namespace, or you may decide to export on demand (by using the @EXPORT_OK array instead) rather than exporting by default as the above example does (export on demand is often the better choice, so the caller gets to choose what to import into its namespace). Had I used the @EXPORT_OK array instead, then my calling program could have said: use MyPack qw/bar/;, and only the bar() routine would have been imported into its namespace (but the caller could still access $MyPack::foo).

[reply]
[d/l]
[select]