Front page | perl.perl5.porters |
Postings from December 2015
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/KENTNL
Thread Previous
|
Thread Next