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:
Chad Granum
Date:
December 22, 2015 16:27
Subject:
Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm
Message ID:
CAJFr3ktyAb+_nhkJzAiuvktf9CkP=iuKX6E1MD69XA2cgY0bgw@mail.gmail.com
The way I am handling groups is this: First the import list is scanned for
the hashes, which are put into a hash where the symbol is the key. Then
Exporter.pm does its thing to expand @imports (include symbols in tags or
pattern matches). Then Exporter.pm iterates over the imports to export
them, for each one it looks for the symbol in the hash to find the
{-as=>...} hash associated with the symbol, if none is found exporting is
normal, if one is found it exports it under the new name. This allows
someone to specify a group, and rename select symbols within the group by
specifying them again with the hash.

On Mon, Dec 21, 2015 at 4:12 PM, Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> tl;dr -- I think adding this feature as described is the right choice.
> We'll
> probably want to make a couple little tweaks and make sure we've got good
> test
> coverage.
>
> 1.  Should we extend Exporter to allow aliasing?
>
>     PRO1: It's really useful.
>     CON1: Other exporters don't benefit.
>     CON2: If other exporters implement it differently, it's more to learn.
>     CON3: Putting this in Exporter could lead to subtle prereq action at a
>           distance.
>
>     I'm going to put CON3 aside.  If that's the only objection left, in the
>     end, it's not enough for me.
>
>     CON1 and CON2 are addressed by the same means:  a tool for doing
> aliased
>     importing on arbitrary importing modules.  Something like:
>
>       use aliasing 'Package', [ orig1 => 'new1', orig2 => 'new2 ];
>
>     This won't handle groups.  Maybe you look at all the symbols imported
> to
>     the intermediate package, then alias those.  So maybe you provide a
> mapping
>     table as the last argument, and use that to transform the new symbols
>     found.
>
>       use aliasing 'Package', ':stuff', [ orig1 => 'new1', qr/./ => sub
> {...} ];
>
>     That might handle many more cases, but it still chokes on imports that
> want
>     to inspect their caller() to work, because the intermediate package is,
>     perforce, the caller.
>
>     So, this is clearly going to work only on some subset of exporters.  At
>     what point is the subset so large that it's worth adding this special
> tool,
>     rather than just putting the feature into Exporter?
>
>     Alternately: how often will the importing user know that it is safe to
> use
>     the renaming import wrapper?  What if the exporter changes its
> contract?
>     Does it need to advertise compatibility?
>
>     I don't think the little difficulties introduced by saying "we won't
> add
>     this, you should use a wrapper" are worth it.  Providing the feature in
>     Exporter will work, even if you do feel the need to say "use Exporter
>     1.234" before trying to use it.
>
> 2.  Is the { -as => "newname" } implementation the right one?
>
>     Well, I think I pioneered this form of this feature in Sub::Exporter,
> so
>     I'm partial to it... but in Sub::Exporter, that hashref can contain all
>     sorts of other things that can be put to use.  In Exporter, not so
> much.
>     Would it be better to provide a less "open" data structure for this
>     mapping, like a list of pairs, marked off by some kind of sentinel?
> (For
>     example, an arrayref of pairs.  The exact form is not necessarily
>     interesting.)
>
>     I'm not really sold.  I think the hashref is okay.  We can validate
> that
>     the only entry in it is "-as", to prevent crazy mistakes.
>
>     Someone mentioned that this doesn't support groups. This is correct.
> In
>     Sub::Exporter, groups can take a similar argument, which can contain
>     -prefix or -suffix.  We could also provide that.
>
>       use Pies ':savory' => { -prefix => 'yummy_' };
>       use Cake::Const "/^CK_/" => { -suffix => '_CONST' };
>
>     I'm not too worried about making this look like anything else that
> uses it.
>     That's a nice little benefit, but there will be other differences, so
>     people will want to know what's under the hood.  I just want it to be
> easy
>     to skim and understand, and this passes that test.
>
> --
> rjbs
>

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