use My::Package; basically is
BEGIN { require My::Package; My::Package->import(...); };
Your first question relates to that - the eval delays the execution of the use statement until after compile time, which means that the print Dumper ... line gets interpreted as print {Dumper} ..., that is a print to a filehandle named Dumper. You could disambiguate that by using
print Dumper(...);
The answer to your second question will be clear when you look, again, at what use really is:
# use Durf; # basically is BEGIN { require Durf; Durf->import(...); };
... and as there is no file Durf.pm (or Durf.pmc), this fails. Just leave out the use line and you'll be allright. There are other ways to trick require (and <c>use) into not going looking for a file, but not calling require is the easiest.
Dynamically loading packages should, again, be done at compile time, especially if you want the constant names to be interpreted as subroutines/constants:
BEGIN { for (@ARGV) { eval "use $_; 1" or die $@; # don't forget to reraise module errors }; };
In reply to Re: eval use, local packages, and use constants
by Corion
in thread eval use, local packages, and use constants
by deep submerge
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |