On 19 December 2015 at 12:39, demerphq <demerphq@gmail.com> wrote: > > I think that is entirely the wrong approach to problems like this. Well, sometimes you have to ask a question before you work out if it would make sense to ask that question. :) But I would suspect if I were to think there's potential where it could go wrong, I'd be looking at things like: How could Exporter break if somebody had things in there anyway, wrapping `import` in some kind of filter before handing it over to Exporter->import() to finish the job? How will failure cases be handled with the new import syntax on old exporters. This can be a bit of fun for dependency management reasons. Because you'll have a case where you have: X -> an Exporter Y -> wants renaming support from X which means you'll have people just doing: use X y => { -as => q[foo] }; And dependency checking will only ever predict that they need any version of "X". So people will need to explicitly state they're using new exporter syntax: use Exporter 3.1415 (); # rename support for X use X y => { -as => q[foo] }; And then you'll have somebody mess *that* up at some point and you'll have a CPAN release that doesn't get installed enough to fix its update tree, leaving anything that depends on Y having additional things they have to do in dependencies. This is not a problem *unique* to Exporter.pm, but the "new interface at a distance" adds a special level of pain potential. -- Kent KENTNL - https://metacpan.org/author/KENTNLThread Previous | Thread Next