2008/6/20 Ovid <[EMAIL PROTECTED]>: > 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:
# 2008 use Foo; # exports nothing use Bar; # exports set with Exporter::Safe set() # Bar # 2009 after upgrading some modules use Foo; # new version in 2009 exports set use Bar; # exports set with Exporter::Safe set() # now Foo and triggers rm -rf / :) Of course switching the order of imports gives the problems without Exporter::Safe. The upshot is that I believe there is no such thing as safe default exports. Python gets this right with import Foo import Bar Bar.set() # always works no matter what Foo suddenly starts doing. It deals with long package names by doing from Stupid.Long.Package import Name Name.Foo So, what would be interesting would be to find a way to bring the short name in my current namespace ebenefits of Python to Perl and abandon default exports entirely, F > use Test::Most plan => 3, '+set'; > > Are there better strategies? > > Cheers, > Ovid > > -- > Buy the book - http://www.oreilly.com/catalog/perlhks/ > Personal blog - http://publius-ovidius.livejournal.com/ > Tech blog - http://use.perl.org/~Ovid/journal/ >
