J
Jim Thomason
I'm strongly leaning towards declaring this a bug and being done with
it, but I wanted to ask here to see if anyone can explain it. I have 2
packages, which use each other.
======
package a
======
package a;
use strict;
use warnings;
use b;
sub foo_a {print "a in foo\n"};
1;
======
package b
======
package b;
use lib '.';
use a qw(from b);
sub foo_b {print "b in foo\n"};
1;
===
All well and good. a uses b. b uses a.
So, here's my connundrum:
[kalel:~] jim% perl -c a.pm
Subroutine foo_a redefined at a.pm line 13.
a.pm syntax OK
But:
[kalel:~] jim% perl -Ma -e '1'
[kalel:~] jim%
Further testing has demonstrated that in all cases I can throw at it, if
I -c a module with a circular use, I get a warning about a redefined
subroutine. However, if I use the module as part of a script, I get no
warning.
Additionally, one thing that I've isolated is that if I use a script,
then %INC is populated immediately. Here:
=====
new package a
=====
package a;
BEGIN {print "BEGINNING IMPORT OF a\n"};
BEGIN {print map {"a> $_ => $INC{$_}\n"} keys %INC};
use strict;
use warnings;
use lib '.';
use b;
sub foo_a {print "a in foo\n"};
1;
#!/usr/bin/perl
use strict;
use warnings;
BEGIN {print map {"w> $_ => $INC{$_}\n"} keys %INC};
use a;
[kalel:~] jim% ./test.pl
w> Exporter.pm => /System/Library/Perl/Exporter.pm
w> Carp.pm => /System/Library/Perl/Carp.pm
w> strict.pm => /System/Library/Perl/strict.pm
w> warnings.pm => /System/Library/Perl/warnings.pm
BEGINNING IMPORT OF a
a> Exporter.pm => /System/Library/Perl/Exporter.pm
a> Carp.pm => /System/Library/Perl/Carp.pm
a> strict.pm => /System/Library/Perl/strict.pm
a> warnings.pm => /System/Library/Perl/warnings.pm
a> a.pm => a.pm
Note that %INC comes in with values.
However,
[kalel:~] jim% perl -c a.pm
BEGINNING IMPORT OF a
BEGINNING IMPORT OF a
a> Exporter.pm => /System/Library/Perl/Exporter.pm
a> Carp.pm => /System/Library/Perl/Carp.pm
a> b.pm => b.pm
a> strict.pm => /System/Library/Perl/strict.pm
a> Config.pm => /System/Library/Perl/darwin/Config.pm
a> warnings.pm => /System/Library/Perl/warnings.pm
a> a.pm => a.pm
a> lib.pm => /System/Library/Perl/lib.pm
Subroutine foo_a redefined at a.pm line 14.
a.pm syntax OK
The first time that a.pm is imported, %INC is unpopulated in any form.
Only once b.pm uses a, does %INC get populated.
Incidentally, best as I can tell, a is used, then b is used, which uses
a. This subsequent use of a compiles the subroutine. b then finishes
compiling and the stack reverts back to compiling a, which re-compiles
the same subroutine. moving the 'use b' line in a to the end of the file
only succeeds in changing the order in which the subroutine is
re-defined (i.e., it's first compiled as part of 'a', then 'b' uses 'a'
and re-compiles it)
Now, to me, this is all rather buggy behavior. Especially considering
the fact that it warns me with -c a.pm but not with my test script (or
-Ma -e '1'
So, is there a clear explanation of this phenomenon? Or should I just
declare it a bug and be done with it?
FWIW, I see the same problem under 5.6.0 on OS X (10.2.6) and 5.8.0
under linux (dunno the distro)
Thanks,
-Jim......
it, but I wanted to ask here to see if anyone can explain it. I have 2
packages, which use each other.
======
package a
======
package a;
use strict;
use warnings;
use b;
sub foo_a {print "a in foo\n"};
1;
======
package b
======
package b;
use lib '.';
use a qw(from b);
sub foo_b {print "b in foo\n"};
1;
===
All well and good. a uses b. b uses a.
So, here's my connundrum:
[kalel:~] jim% perl -c a.pm
Subroutine foo_a redefined at a.pm line 13.
a.pm syntax OK
But:
[kalel:~] jim% perl -Ma -e '1'
[kalel:~] jim%
Further testing has demonstrated that in all cases I can throw at it, if
I -c a module with a circular use, I get a warning about a redefined
subroutine. However, if I use the module as part of a script, I get no
warning.
Additionally, one thing that I've isolated is that if I use a script,
then %INC is populated immediately. Here:
=====
new package a
=====
package a;
BEGIN {print "BEGINNING IMPORT OF a\n"};
BEGIN {print map {"a> $_ => $INC{$_}\n"} keys %INC};
use strict;
use warnings;
use lib '.';
use b;
sub foo_a {print "a in foo\n"};
1;
#!/usr/bin/perl
use strict;
use warnings;
BEGIN {print map {"w> $_ => $INC{$_}\n"} keys %INC};
use a;
[kalel:~] jim% ./test.pl
w> Exporter.pm => /System/Library/Perl/Exporter.pm
w> Carp.pm => /System/Library/Perl/Carp.pm
w> strict.pm => /System/Library/Perl/strict.pm
w> warnings.pm => /System/Library/Perl/warnings.pm
BEGINNING IMPORT OF a
a> Exporter.pm => /System/Library/Perl/Exporter.pm
a> Carp.pm => /System/Library/Perl/Carp.pm
a> strict.pm => /System/Library/Perl/strict.pm
a> warnings.pm => /System/Library/Perl/warnings.pm
a> a.pm => a.pm
Note that %INC comes in with values.
However,
[kalel:~] jim% perl -c a.pm
BEGINNING IMPORT OF a
BEGINNING IMPORT OF a
a> Exporter.pm => /System/Library/Perl/Exporter.pm
a> Carp.pm => /System/Library/Perl/Carp.pm
a> b.pm => b.pm
a> strict.pm => /System/Library/Perl/strict.pm
a> Config.pm => /System/Library/Perl/darwin/Config.pm
a> warnings.pm => /System/Library/Perl/warnings.pm
a> a.pm => a.pm
a> lib.pm => /System/Library/Perl/lib.pm
Subroutine foo_a redefined at a.pm line 14.
a.pm syntax OK
The first time that a.pm is imported, %INC is unpopulated in any form.
Only once b.pm uses a, does %INC get populated.
Incidentally, best as I can tell, a is used, then b is used, which uses
a. This subsequent use of a compiles the subroutine. b then finishes
compiling and the stack reverts back to compiling a, which re-compiles
the same subroutine. moving the 'use b' line in a to the end of the file
only succeeds in changing the order in which the subroutine is
re-defined (i.e., it's first compiled as part of 'a', then 'b' uses 'a'
and re-compiles it)
Now, to me, this is all rather buggy behavior. Especially considering
the fact that it warns me with -c a.pm but not with my test script (or
-Ma -e '1'
So, is there a clear explanation of this phenomenon? Or should I just
declare it a bug and be done with it?
FWIW, I see the same problem under 5.6.0 on OS X (10.2.6) and 5.8.0
under linux (dunno the distro)
Thanks,
-Jim......