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

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

Thread Previous | Thread Next
From:
David Golden
Date:
December 19, 2015 03:58
Subject:
Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm
Message ID:
CAOeq1c87moDH9X4pcVSdmgkbsjU9FaWsO0pEcOiJi+S0PSz9gw@mail.gmail.com
On Fri, Dec 18, 2015 at 10:45 PM, Aristotle Pagaltzis <pagaltzis@gmx.de>
wrote:

>
> 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



-- 
David Golden <xdg@xdg.me> Twitter/IRC/Github: @xdg

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About