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:
Kent Fredric
Date:
December 18, 2015 23:37
Subject:
Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm
Message ID:
CAATnKFDnV4i32EHFSbfbw8OTxgt-0PQ=CnKGLkUdP+OZjt_wZA@mail.gmail.com
On 19 December 2015 at 11:54, David Golden <xdg@xdg.me> wrote:
> I think you should answer the opposite question first.  Why does this
> behavior need to be in core when there are already alternatives on CPAN?
> Note, I consider "so people can have fewer dependencies" uncompelling on its
> own as there are many things that could go into core on that basis that we
> haven't and wouldn't put into core.
>
> Until there is a compelling case for why it should go into core, I oppose
> adding it.
>
>>
>> 3) Are there any good technical reasons not to do this?
>
>
> Having a module that depends on a newer version of Exporter will require
> users of Perls before v5.24 to install Exporter from CPAN instead of relying
> on their existing core Exporter.  Thus, this will not minimize dependencies
> in general until the general Perl using population switches to v5.24 or
> later.  It may in practice make things worse – growing dependencies – as
> people may be more open to depending on a newer version of a core module
> than they would be about depending on Sub::Exporter or other CPAN module.

Lacking this feature in Exporter means 2 things:

1. Any module that presently uses Exporter.pm for an interface cannot
have the consumer utilize renaming.  Instead of the consumer having
control over whether they want that feature, the lack of the feature
in Exporter demands consumers of modules request their modules switch
to some other exporter.

This means for users to experience renaming, they'd have to encourage
all their dependencies to depend on more complex things available only
from CPAN.

2. Any Core module suffers problem 1, with the additional complication
that it can never satisfy its users who request renaming support,
because the added dependency is forbidden, so to support it,
hand-inlining the equivalent feature would be required for all core
modules. And that would be much worse to actually do that than to
provide the same features directly in Exporter.pm

That said, the frequency at which one needs renaming in my experience
is quite low, and that for Exporter.pm, strategies such as
Import::Into::As are fine.

And instead, one might find it more pragmatic to design a low level
"import_as()" interface API so tools that need exporter-chaining can
just call that method instead if it exists, and then power users can
do the awkward dance with

BEGIN { require Foo; Foo->import_as( .... ) }

Or something like that.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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