develooper Front page | perl.perl5.porters | Postings from December 2015

Re: Proposal: Add {-as => 'new_name'} feature to

Thread Previous | Thread Next
David Golden
December 19, 2015 03:58
Re: Proposal: Add {-as => 'new_name'} feature to
Message ID:
On Fri, Dec 18, 2015 at 10:45 PM, Aristotle Pagaltzis <>

> Moreover, even in cases where it does happen, it won’t be existing code
> that breaks but only newly written, when its author tries using renamed
> imports and finds they don’t work. So this form of monkey-patching does
> not seem problematic.

Module X uses Exporter.
Module Y uses X and requires Exporter 3.1415 to get aliasing on X.
Module Z uses Y
I use Module Z.
Module X wraps import() for some reason.
New Module X gets upgraded on my system (or newly deployed)
When I use Module Z, Module X does something surprising.
I report the error to author of Module X, who doesn't know what the hell
I'm talking about.
We discover the problem is with Module Y.
I report the error to author of Module Y.
Author of Module Y updates it to work around Module X's wrap (if they
haven't done so already).
I upgrade Module Y (or re-deploy) to get the fix.

Alternatively, author of Module::Y can just manually alias a function from
X and nothing breaks when X changes.

I agree about the Exporter::Rename proposal dealing with this, too, as it
makes X opt-in, except at that point you're still adding a module to core
that people have to use to benefit.  Why not add Exporter::Tiny (or
alternatives) and get all the extra features instead of Exporter plus a
tiny bit of sugar?


David Golden <> Twitter/IRC/Github: @xdg

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About