sub begin_work {
use Data::Dumper;
... lotsa code
no Data::Dumper;
return;
}
This doesn't address your immediate problem, but application code
modules like Data::Dumper do not follow the lexical
scoping rules that pragma modules like strict,
warnings and integer follow.
The effects of the use Data::Dumper; statement are seen from
the point in the file at which the module is use-ed at
compile time and in all code beyond that point.
Win8 Strawberry 5.8.9.5 (32) Sun 01/10/2021 10:52:26
C:\@Work\Perl\monks
>perl -Mstrict -Mwarnings
# pm#11126693
foo(); # try disabling this statement
print Dumper [ qw(1 2 3) ]; # print() on unopened filehandle Dumper
# foo(); # try enabling this statement
sub foo {
use Data::Dumper;
print Dumper [ qw(a b c) ];
no Data::Dumper; # has no effect
print Dumper [ qw(x y z) ];
}
print Dumper [ qw(9 8 7) ]; # prints as expected
^Z
$VAR1 = [
'a',
'b',
'c'
];
$VAR1 = [
'x',
'y',
'z'
];
print() on unopened filehandle Dumper at - line 5.
$VAR1 = [
'9',
'8',
'7'
];
Same results running under Perl version 5.30.3.1.
Update: Another little twist to consider is the effect of
adding a declaration of the Dumper subroutine in the
main package before the first call to Dumper
(and before the use Data::Dumper; statement):
sub Dumper;
print Dumper [ qw(1 2 3) ]; # print() on unopened filehandle Dumper
What happens and why? Is there another way to identify Dumper
to the compiler as a subroutine? What would happen if one wrote:
### sub Dumper;
print Dumper([ qw(1 2 3) ]); # print() on unopened filehandle Dumper
(I see the same results under both versions 5.8.9 and 5.30.3.)
Give a man a fish: <%-{-{-{-<
|