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:
Aristotle Pagaltzis
Date:
December 19, 2015 03:26
Subject:
Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm
Message ID:
20151219032614.GA35482@plasmasturm.org
* Kent Fredric <kentfredric@gmail.com> [2015-12-19 01:05]:
> This can be a bit of fun for dependency management reasons.

A bit fun, ha ha ha, you jokester. *crying*

> So people will need to explicitly state they're using new exporter
> syntax:
>
>     use Exporter 3.1415 ();   # rename support for X
>     use X y => { -as => q[foo] };
>
> And then you'll have somebody mess *that* up at some point and you'll
> have a CPAN release that doesn't get installed enough to fix its
> update tree, leaving anything that depends on Y having additional
> things they have to do in dependencies.
>
> This is not a problem *unique* to Exporter.pm, but the "new interface
> at a distance" adds a special level of pain potential.

Yeah, ughhhh. I hadn’t even thought ahead that far.

I *think* it is possible to solve this by requiring the user to enable
the new feature:

    package Y;
    use Exporter::Rename;
    use X y => { -as => q[foo] };

More specifically, Exporter::Rename must add package Y to a whitelist
and Exporter must then check that whitelist before it does any renaming.
In non-whitelisted packages you get the old Exporter behaviour, to avoid
action at a distance.

This way the dependency is forcibly made explicit, making it trivially
visible to tooling and such.

Yes?

It’s ugly, but I’ll consider that a feature: syntactic salt to remind
authors that there is a dependency cost to this feature.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

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