develooper Front page | perl.perl5.porters | Postings from December 2015

Re: Proposal: Add {-as => 'new_name'} feature to

Thread Previous | Thread Next
Chad Granum
December 22, 2015 16:27
Re: Proposal: Add {-as => 'new_name'} feature to
Message ID:
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 does its thing to expand @imports (include symbols in tags or
pattern matches). Then 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 <>

> 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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About