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:
Abigail
Date:
December 21, 2015 13:07
Subject:
Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm
Message ID:
20151221130710.GB6918@almanda.fritz.box
On Fri, Dec 18, 2015 at 10:57:30PM -0500, David Golden wrote:
> 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.


But that's not a new problem, isn't? Even without the proposed fix, if
Y uses "use X '/pattern/'" and X gets updated to roll its own exporting,
and you install the new X, your module Z will break.

The problem here isn't a new feature to Exporter, it's X ditching Exporter.

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


The problem here is, "makes X opt-in". Assuming a miracle happens and
every CPAN authors decides within a month [1] whether to opt their modules
in or not, CPAN has now two groups of modules: those that haven't opt-in,
and don't make it easy to export to a different name, and those that
have opted in, and will break their downstream when switching exporters.
Are we than in a better situation then just adding the proposed feature?
My opinion is, we aren't.




Abigail

[1] In practise, after many years, people will not have made that decision.
    It will take years before Joe R. CPANauthor even realizes there's a
    choice to be made.

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