About your "our" comment: "our" does not actually define a variable, it simply makes the global variable $foo::zm available as "$zm" in the local (lexical) context. Since you have two different local contexts (two files), you need to use "our" both times so you can use "$zm" both times.
Here's some module theory, all about circular references and loading order: First of all you need some some background info to "use" and "require":
require Foo::Bar;
translates to
eval(getModuleFileContents("Foo/Bar.pm")) unless isAlreadyLoaded("Foo/Bar.pm");
and
use Foo::Bar @args;
translates to
BEGIN {
require Foo::Bar;
Foo::Bar::import(@args) unless !defined *Foo::Bar::import{CODE};
}
Circular loading is perfectly legal, but in that case you shouldn't ever rely on loading order, because it can change for the slightest of reasons.
For example, here's what could go wrong:
package Foo;
require Bar;
our $foo = 3;
package Bar;
require Foo;
our $bar = $Foo::foo + 2;
require Foo;
require Bar;
print $Bar::bar;
require Bar;
require Foo;
print $Bar::bar;
These two programs have different results: main1.pl prints 2, and main2.pl prints 5. That is because in main1.pl, the line "our $bar = $Foo::foo + 2;" is called before the line "our $foo = 3;".
To avoid such shenanigans, you have to take care when writing the static code for a module (static code is the code outside subroutines): A module's static code may never ever assume any modules to be loaded that it is in a circular loop with. Defining subroutines is always okay, since the subroutines won't be executed until all modules are loaded, but the static code should never depend upon its circularly dependent modules.
So basically, here's how a multi-file program is structured:
* 1 main executable file. This file is the one that gets run, and it shall never ever be require'd.
* Lots of .pm files. These should only contain subroutine definitions and some simple variable initializations:
package Foo;
use Bar; ## Bar uses Foo too, so we need to be careful
use SomeLib; ## SomeLib is definitely not dependent on Foo, so we can use it
$a = 1; ## Perfectly fine
$b = SomeLib::blah(); ## Fine: Since SomeLib doesn't need Foo, we know that SomeLib is already loaded by now
$c = Bar::bar(); ## WRONG: We don't know if Bar's been loaded yet, so we may not use Bar's stuff
sub foo {
my $k = $a;
my $p = SomeLib::bluh();
my $n = Bar::bar(); ## CAUTION: Since Bar is being used, this subroutine is "non-static" (it should not be called in Foo's static code).
return ($k, $p, $n);
}
sub fooo {
foo(); ## CAUTION: Since foo is a non-static function, this makes fooo a non-static function too.
}
sub noot {
return SomeLib::bleh() + 4; ## This subroutine is perfectly harmless; we may call it in Foo's static code. Keep in mind though that we are still not allowed to use it in Bar's static code due to the circular dependency.
}
foo(); ## WRONG
fooo(); ## WRONG
noot(); ## OKAY
1;
Oh, and by the way, so you don't trip over this: Never use Exporter twice in the same package (even in different files), it WILL have unexpected issues unless you know exactly what Exporter is doing, and it wouldn't really ever be necessary anyway.
Author
Topic: if self.isCoder(): post() #Programming Thread (Read 883259 times)