Behaviour on recursive use

locinus33 has asked for the wisdom of the Perl Monks concerning the following question:

Hello monks.

I suppose recursive 'uses' should be avoided in general cases, but still, I'd like to understand what's going on with this simple code: A1 and A2 are using C, which uses A2. Warning and strict are used in all files.

File A1.pm

package A1;
use A2;
use C;
sub functionA
{
    print "In A1: ".C::TYPE->{VEG}."\n";
    A2::functionA();
}
[download]

File A2.pm

package A2;
use C;
sub functionA
{
    print "In A2: ".C::TYPE->{VEG}."\n";
}
[download]

File C.pm

package C;
use A2;
use constant {
    TYPE => {
        FRUIT => 1,
        VEG => 2,
        MEAT => 3,
    },
};
[download]

Now we can test:

use A2;
A2::functionA(); # prints "In A2: 2"
[download]

and

use A1;
A1::functionA(); # prints "In A1: 2\nIn A2: 2"
[download]

Right. But if we inverse the order of 'use' in A1.pm, so C is 'used' before A2, the second test leads to a non-understanding of external constant TYPE: "Can't use bareword ("C::TYPE") as a HASH ref while "strict refs" in use at A2.pm line 7". Why so?

Question 2: If we keep this order, I can fix the problem by calling in A2.pm "C->TYPE->{VEG}" instead of "C::TYPE->{VEG}". Enlightenments welcome! : )

Cheers.

Locinus (perl v5.12.3 built for MSWin32-x86-multi-thread)

Comment on Behaviour on recursive use Select or Download Code

Replies are listed 'Best First'.
Re: Behaviour on recursive use by tobyink (Canon) on Mar 05, 2014 at 21:53 UTC
It's not a problem from perl's perspective, but behaviour in the case of circular requires can sometimes be a little unintuitive: `# foo.pm package foo; use bar; sub import { printf("%s loaded foo\n", scalar caller) } 1;` [download] `# bar.pm package bar; use foo; sub import { printf("%s loaded bar\n", scalar caller) } 1;` [download] `# script.pl use foo;` [download] Running the script, generates the following output: `foo loaded bar main loaded foo` [download] Did you expect to see `bar loaded foo` somewhere in that output? With careful consideration of compile time versus runtime, etc, etc, you'll realise why that line was not output, and that this is proper and documented behaviour. Just not necessarily very intuitive. `use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name`	[reply] [d/l] [select]
Re^2: Behaviour on recursive use by locinus33 (Initiate) on Mar 10, 2014 at 10:32 UTC
Fair enough. Thank you for leading me in the way. So, according to the imports order, the compiler will or won't load the different variables/subs in the right order, so that in my example, we have : `========= OK test : load A1 -> load A2 -> load C (but constant TYPE is not loaded already) -> not load A2 (already 'used') -> load constant TYPE ========= KO test : load A1 -> load C (but constant TYPE is not loaded already) -> load A2 -> not load C (already 'used') -> fail because constant TYPE is not loaded` [download] Is that right? Ok. What about the "C->TYPE" vs "C::TYPE", the first being the one that always works whatever the 'use' order. Is that a "runtime" vs "compile time", as you pointed out? Cheers.	[reply] [d/l]
Re^3: Behaviour on recursive use by Anonymous Monk on Mar 10, 2014 at 10:57 UTC
Ok. What about the "C->TYPE" vs "C::TYPE", the first being the one that always works whatever the 'use' order. Is that a "runtime" vs "compile time", as you pointed out? C->TYPE is method call (like "C"->TYPE or "C::"->TYPE or C::->TYPE ) and C::TYPE is a bareword C::TYPE can be a function call or it can be a namespace , perl doesn't know ahead of time what it is Once the constant C::TYPE is defined (constants are functions ) perl knows that C::TYPE is a function, so the code becomes C::TYPE()->... and not "C::TYPE"->... If you write C::TYPE()->... perl knows ahead of time, before the TYPE constant is actually defined to treat it as a function call This is talked about in perlobj and maybe even Modern Perl , so see those for more of these detail Bottom line, lots of experts think having two modules use each other is mistake -- they should both use a third module -- you're not alone in trying this :) Circular module dependencies, Circular usage is poor design if you can't figure it out yourself, that is a giant hint that you should break the circle Also, complex constants like these are, well, overrated in practice :) Maybe see also Simple Module Tutorial and begincheck.pl and Circular use doesn't call import() as expected...? Cheers, I'm just some nightowl	[reply]
Re^4: Behaviour on recursive use by locinus33 (Initiate) on Mar 10, 2014 at 15:47 UTC
Re: Behaviour on recursive use by Laurent_R (Canon) on Mar 05, 2014 at 19:49 UTC
I suppose recursive 'uses' should be avoided in general cases... Well, it can't be avoided in many cases. Numerous modules use other modules, so that you can end up with a fairly complicated dependency tree. The good thing about use is that if the dependency tree calls the same modules several times, the module will be loaded only once. Having said that, you obviously have to be a bit careful with the order in which you load modules, and it can sometimes be an headache if the dependency tree is large.	[reply]