Re: Exporter not behaving as expected

@rry isn't declared in case 1 because you didn't export anything (@EXPORT = ();).

Case 2 prints zero since you never assign anything to the array named rray in the MyModule namespace. my creates a lexical variable (i.e. one that's only seen in the lexical scope where it's declared), not a package variable (i.e. one that's located in a package and visible everywhere).

Just like your script can't see the lexical variable since it's out of scope, Exporter can't see it either. As such, Exporter exports package variables. Case 3 is therefore exports the same variable that you accessed in case 2, a package variable to which you never assigned anything.

Solutions:

@MyModule::rray = (1, 2, 3, 4) instead of my @rray = (1, 2, 3, 4);.
use vars qw( @rray ); @rray = (1, 2, 3, 4) instead of my @rray = (1, 2, 3, 4);.
our @rray = (1, 2, 3, 4) instead of my @rray = (1, 2, 3, 4);.

Comment on Re: Exporter not behaving as expected Select or Download Code

Replies are listed 'Best First'.
Re^2: Exporter not behaving as expected by davies (Monsignor) on Mar 27, 2015 at 18:14 UTC
Thanks. I've got confused over the difference between my & our before. I thought I had understood the difference, but obviously I hadn't. Your solution works perfectly, so I clearly have some reading to do. Thanks again & regards, John Davies	[reply]
Re^3: Exporter not behaving as expected by ikegami (Patriarch) on Mar 27, 2015 at 18:19 UTC
`our` creates a lexical variable which is aliased to the package variable of the same name in the package where the `our` is located. `our $foo;` [download] isbehaves the same as `alias my $foo = $MyModule::foo;` [download]	[reply] [d/l] [select]
Re^4: Exporter not behaving as expected by LanX (Saint) on Mar 27, 2015 at 20:45 UTC
> our creates a lexical variable which is aliased to the package variable of the same name in the package where the our is located. > `our $foo;` > is the same as > `alias my $foo = $MyModule::foo;` not exactly, it's never a variable from the lexical pad - aliased or not - it's only a lexically scoped package var. (i.e. a compile time effect) `~$ perl -MO=Terse -e 'package foo; our $x; package bar;print $x+$a' LISTOP (0x820dd70) leave [1] OP (0x820e2d8) enter COP (0x820cc00) nextstate UNOP (0x820dd90) null [15] PADOP (0x820cb90) gvsv GV (0x8208700) foo::x COP (0x820ddb0) nextstate LISTOP (0x823e218) print OP (0x8205710) pushmark BINOP (0x820df38) add [5] UNOP (0x820dd30) null [15] PADOP (0x820dcf0) gvsv GV (0x8208700) foo::x UNOP (0x820cbb0) null [15] PADOP (0x82046c0) gvsv GV (0x820869c) bar::a -e syntax OK` [download] but I have to admit that "lexical variable" has an ambiguity. Though checking in `perlglossary` clearly defines lexical variable A "variable" subject to "lexical scoping", declared by my. Often just called a "lexical". (The our declaration declares a lexically scoped name for a global variable, which is not itself a lexical variable.) update OTOH is aliasing in Perl always a compile time effect, so your interpretation is not really wrong regarding the effect ... Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :)} PS: Je suis Charlie!*	[reply] [d/l] [select]

lexical variable

update