| Subject: | modules capturing import vs "no Exporter::Renaming" |
| Date: | Thu, 08 Apr 2010 07:42:13 +1000 |
| To: | bug-Exporter-Renaming [...] rt.cpan.org |
| From: | Kevin Ryde <user42 [...] zip.com.au> |
If a module takes a coderef \&Exporter::import while Exporter::Renaming
is in force, then renaming is turned off, further uses of that coderef
don't work. For example roman.pl below gets an error
Use of uninitialized value $exporter_import in subroutine dereference at /usr/share/perl5/Exporter/Renaming.pm line 36.
Unable to create sub named "" at /usr/share/perl5/Exporter/Renaming.pm line 36.
BEGIN failed--compilation aborted at roman.pl line 8.
That Roman.pm is following the Exporter pod under "Exporting without
inheriting from Exporter". I don't think modules doing that will work
properly with Exporter::Renaming (because they don't see the switching
of Exporter::import(), only what was in force when they loaded), but
it'd be good if Exporter::Renaming did no harm to them though.
Maybe renaming_import() could notice if it's called when renaming is
disabled, and go to the plain Exporter::import() in that case.
use strict;
use warnings;
use Exporter::Renaming;
use Roman;
no Exporter::Renaming;
use Roman 'Roman';
print Roman(123),"\n";