Front page | perl.perl5.porters |
Postings from December 2015
* 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