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 02:56
Subject:
Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm
Message ID:
CAOeq1c-P8nVYDJ+p_Du5vUYUP7Vd9h=DCfC2OcwA6Nbq711pow@mail.gmail.com
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.  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 think what will happen is:

    use X 1.234 y => { -as => q[foo] };

Where X 1.234 requires Exporter 3.1415.  And that's where I see little
difference from X 1.324 requiring Exporter::Foo from CPAN.  In both cases,
there's a CPAN dependency except for people running on the very latest Perl.

Here's the (social) problem I see:

(1) Assume that I want to alias the imports from X and X doesn't support
that

(2) I ask the author of X to switch to an importer that supports it.
Outcomes:

  (2a) Author switches, adding a dependency on Exporter::* from CPAN; my
problem is solved
  (2b) Author doesn't switch, citing the desire not to add a dependency; I
am still stuck
  (2c) Author is absentee or doesn't want to do the work for a
non-dependency related reason; I am still stuck

(3)  Assume a newer Exporter 3.1415 with the -as feature, how would (2b)
outcomes change (i.e. still no use of Exporter::* from CPAN)

  (3a) Author adds dependency on new Exporter 3.1415; my problem is solved
  (3b) Author doesn't want to depend on newer Exporter, citing desire not
to add a dependency for older Perls; I am still stuck

(4) If I want to alias a lot, I have to do steps above for every module Y,
Z, P, D and Q

So for me to benefit from this proposed Exporter feature, there need to be
a lot of authors who wind up at (2b) today but would take option (3a) if
available.  And by the time that happens, I've probably gone ahead and
worked around the lack of aliasing anyway.  C<< BEGIN { require X; *foo =
&X::y } >>.

Thus, I see the net benefit as pretty minimal unless one is looking out 10
years when we can assume that everyone is running Perl 5.22.  Maybe people
think that investment is worth it.  But maybe people think the cost of
proliferating Exporter into the dependency chain in the meantime for older
Perls isn't worth it.

And maybe people see other costs and benefits that I haven't covered here.

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