in reply to Circular module dependencies

Howdy!

I'm going to number the lines so it's easier to follow the flow...

1 package a; 2 BEGIN { 3 use Data::Dumper; 4 print STDERR 'a:',Dumper \%INC; 5 } 6 use b; 7 my $a = { foo => &b::bar () }; 8 1; 9 10 b.pm: 11 12 package b; 13 14 BEGIN { 15 use Data::Dumper; 16 print STDERR 'b:',Dumper \%INC; 17 } 18 use c; 19 sub bar { 1; } 20 1; 21 22 c.pm: 23 24 package c; 25 BEGIN { 26 use Data::Dumper; 27 print STDERR 'c:',Dumper \%INC; 28 } 29 use a; 30 1;
Now, you say perl -c a.pm...that begins at line 1.

Lines 2 through 5 get compiled and immediately executed. Line 6 gets compiled, and leads to b.pm being processed. Move to line 12.

Lines 14-17 get compiled and executed. Line 18 gets compiled and leads to c.pm being processed. Move to line 24.

Lines 24-28 get compiled and executed. Line 29 now causes a.pm to get processed (again). Since a.pm has not yet been required or used, it gets run through the mill a second time. Move to line 1.

Lines 1-8 get compiled, then executed. Since b has already been used, it should get skipped (but import gets run, in the general case). Next, it turns to line 7 and executes it. That attempts to execute b::bar, but we have not yet gotten to line 19 in b.pm to define that subroutine.

Here the execution blows up.

Now, the problem is that you are use-ing modules that do more than define subroutines. When naked code calls routines in other modules, those routines had best be defined before you execute them. Better is to simply avoid getting into those situations.

Consider switching lines 18 and 19 and see what happens...

yours,
Michael