* David Golden <xdg@xdg.me> [2015-12-19 04:00]: > On Fri, Dec 18, 2015 at 6:59 PM, Kent Fredric <kentfredric@gmail.com> wrote: > > > > > use Exporter 3.1415 (); # rename support for X > > use X y => { -as => q[foo] }; > > > If X stops using Exporter or adds some import wrapper later, then this > breaks. Which is why switching exporters is a breaking change. If you expose your exporter’s API to your users directly then its API is your API. > Though arguably, this is just a fancy form of monkey patching, since > in this case Y is pulling in a new Exporter to add behavior to X's > import that it never promised. I agree in that there could be modules that rely on their exports having particular names they control, which would have been reasonable to assume under Exporter so far. That seems rather unlikely though. 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. > I think what will happen is: > > use X 1.234 y => { -as => q[foo] }; Note that my Exporter::Rename proposal addresses this too, if modified to look up both $_[0] and scalar(caller) in the whitelist. Then when X wants to *promise* this interface, *it* can load Exporter::Rename and then any of *its* import() callers would automatically get the feature, and all the dependency relationships trickle out correctly and it works. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next