On Fri, Jun 20, 2008 at 01:45:41PM +0100, Ovid wrote:
> Buried deep within some code, someone used a module (Test::Most 0.03)
> which exports a 'set' function. They weren't actually using that
> module. It was just leftover cruft. Unfortunately, the parent class
> of that module inherited from Class::Accessor.
>
> Test::Most exports 'set' and Class::Accessor calls a 'set' method.
> Oops.
>
> I'm trying to think of the best way to deal with this. My first
> thought is to create a drop in replacement for Exporter which will not
> export a function if caller->can($function) *unless* the person
> explicitly lists it in the import list with a unary plus:
>
> use Test::Most plan => 3, '+set';
>
> Are there better strategies?
How about just disabling all default exports - so ignore @EXPORT and
only look at @EXPORT_OK. Whichever way you go, how about calling it
Import instead of Export, to signify that the *importer* controls
what's happening. A module using this might look like ...
package MyModule;
use Import; # does Magick to make Exporter not work in anything called
# from here
use Module::That::Exports::Stuff; # except that now it doesn't, bwahahahaha!
Import::import(
from => 'Module::That::Exports::Stuff',
subs => [qw(set get bet wet)]
);
--
David Cantrell | top google result for "internet beard fetish club"
Just because it is possible to do this sort of thing
in the English language doesn't mean it should be done
