Sorry for replying to an old thread... but I was catching up on old email. It occurs to me that if we had the behavior that OO method calling would reject any imported modules, wouldn't that solve the problem? I can't think of any reason you would want to use an imported subroutine as an object method. Maybe something akin to strict could be created in a future version of Perl that would thrown an exception whenever you try to invoke a method that was imported using Exporter?
On Fri, Jun 20, 2008 at 5:45 AM, Ovid <[EMAIL PROTECTED]> 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? > > 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/ >
