Sharing global vars with Explorer driving me insane...

[pcaisse]

I'm having issues sharing global variables with Explorer. This problem probably has a simple answer (as with most newbie questions).

The script.pl file:

#!/usr/bin/perl -w
 
use strict;
use diagnostics; 
use sigtrap; 
 
use vars qw($greeting1 $greeting2);
use lib qw(.); 
 
# my modules
 
use ModB qw($greeting1 $greeting2);
use ModA qw($greeting1 $greeting2);
 
$greeting1 = "Hey.";
$greeting2 = "Yo.";
 
ModA::say_hi();
ModB::say_hi();

Pretty straight forward. I have two modules to which I am passing two global scalars that I later want to display. Here's the code for the two modules, ModA and ModB respectively:

ModA.pm:

package ModA;
 
use strict;
 
 
# debug?
my $debug = 0;
 
 
  BEGIN {
    use Exporter ();
 
    @ModA::ISA         = qw(Exporter);
    @ModA::EXPORT      = qw();
    @ModA::EXPORT_OK   = qw($greeting1 $greeting2);
 
  }
 
use vars qw($greeting1 $greeting2);
 
#$VERSION = '0.01';
 
sub say_hi {
 
    print "ModA says " . $greeting2 . "\n";
 
}
 
 
1;

ModB.pm

package ModB;
 
use strict;
 
 
# debug?
my $debug = 0;
 
 
  BEGIN {
    use Exporter ();
 
    @ModB::ISA         = qw(Exporter);
    @ModB::EXPORT      = qw();
    @ModB::EXPORT_OK   = qw($greeting1 $greeting2);
 
  }
 
use vars qw($greeting1 $greeting2);
 
#$VERSION = '0.01';
 
sub say_hi {
 
    print "ModB says " . $greeting1 . "\n";
 
}
 
 
 
 
1;
 

As you can see the two modules are identical aside from their names. My code works fine when I have just one module. However with two, it craps the bed. An interesting side note: the module that produces the error is always the one whose "use" declaration appears first in script.pl. For instance, when script.pl looks like this

.
.
.
use ModB qw($greeting1 $greeting2);
use ModA qw($greeting1 $greeting2);
.
.
.

the error produces looks like this:

./script.pl
ModA says Yo.
Use of uninitialized value in concatenation (.) or string at ModB.pm line 21 (#1)
    (W uninitialized) An undefined value was used as if it were already
    defined.  It was interpreted as a "" or a 0, but maybe it was a mistake.
    To suppress this warning assign a defined value to your variables.
 
    To help you figure out what was undefined, perl tells you what operation
    you used the undefined value in.  Note, however, that perl optimizes your
    program and the operation displayed in the warning may not necessarily
    appear literally in your program.  For example, "that $foo" is
    usually optimized into "that " . $foo, and the warning will refer to
    the concatenation (.) operator, even though there is no . in your
    program.
 
ModB says 

However, switching the order of the "use" statements in script.pl will cause the other module to throw the error:

.
.
.
use ModA qw($greeting1 $greeting2);
use ModB qw($greeting1 $greeting2);
.
.
.

produces

./script.pl
Use of uninitialized value in concatenation (.) or string at ModA.pm line 21 (#1)
    (W uninitialized) An undefined value was used as if it were already
    defined.  It was interpreted as a "" or a 0, but maybe it was a mistake.
    To suppress this warning assign a defined value to your variables.
 
    To help you figure out what was undefined, perl tells you what operation
    you used the undefined value in.  Note, however, that perl optimizes your
    program and the operation displayed in the warning may not necessarily
    appear literally in your program.  For example, "that $foo" is
    usually optimized into "that " . $foo, and the warning will refer to
    the concatenation (.) operator, even though there is no . in your
    program.
 
ModA says 
ModB says Hey.

I hope I've been clear with all that. I really don't get this and any help would be VERY much appreciated.

Thanks,

Pete

[pcaisse]

Wow. I just realized that I could refer to variables in script.pl as $main::my_var. Is this considered bad practice if I'm just passing them one time from script.pl to my modules and not editing them?

[KevinADC]

Your code looks like you're just trying to get the hang of coding modules. If that is the case, it's not doing that very well. Normally you import functions into the main namespace from the modules, and pass variables/data in the system array instead of trying to share global variables. Modules generally have no idea what variables are in the main program, but the main program should know what is in the modules, at least the public interface parts of the module.

[pcaisse]

Your code looks like you're just trying to get the hang of coding modules. If that is the case, it's not doing that very well. Normally you import functions into the main namespace from the modules, and pass variables/data in the system array instead of trying to share global variables. Modules generally have no idea what variables are in the main program, but the main program should know what is in the modules, at least the public interface parts of the module.

Thanks for that clarification. It certainly makes sense for the modules to not know what variables are being used in the main program from a reusibility standpoint. I think I'm going to entirely rework the flow of my program.

[KevinADC]

Here is a sort of standard way to do wht you are trying:

script.pl

#!/usr/bin/perl -w
use strict;
use diagnostics; 
use sigtrap; 
use lib qw(.); 
use ModB qw(say_hey);
use ModA qw(say_hi);
 
my $greeting1 = "Hey.";
my $greeting2 = "Yo.";
say_hi($greeting1);
say_hey($greeting2);

ModA.pm

package ModA;
 
use strict;
# debug?
my $debug = 0;
our( @ISA, @EXPORT, @EXPORT_OK );
require Exporter;
@ISA        = qw(Exporter);
@EXPORT     = qw();
@EXPORT_OK  = qw(say_hi);
 
sub say_hi {
 
    print "ModA says " , shift , "\n";
 
}
1;

ModB.pm

package ModB;
 
use strict;
# debug?
my $debug = 0;
our( @ISA, @EXPORT, @EXPORT_OK );
require Exporter;
@ISA        = qw(Exporter);
@EXPORT     = qw();
@EXPORT_OK  = qw(say_hey);
 
sub say_hey {
 
    print "ModA says ", shift , "\n";
 
}
1;

Of course this is just for learning purposes. It's rather silly to have a module with only one function But you see the main program knows what each module has to offer (the functions) but the modules have no idea what the main program is sending to them. They just echo (print) the value of the scalar variables sent in the function calls. You could code the module functions to have an idea about what type of data they expect to recieve: scalar, array, hash, glob, references, etc, and throw an error if something else is recieved.

If you throw in a constructor and return an object to the main program you have yourself an OO program. Then you can call the objects methods (functions) using the object.