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.
Same results running under Perl version 5.30.3.1.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' ];
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):
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.)### sub Dumper; print Dumper([ qw(1 2 3) ]); # print() on unopened filehandle Dumper
Give a man a fish: <%-{-{-{-<
In reply to Re^3: DBM::Deep: Cannot allocate transaction ID (semi-OT) (updated)
by AnomalousMonk
in thread DBM::Deep: Cannot allocate transaction ID
by fanasy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |