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:28
Subject:
Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm
Message ID:
CAJFr3ksYW1K_ogo8mfPB-AON3JX7mE-ozWUfVQJg2Zy85L30sA@mail.gmail.com
*Note: This is how it is handled in the latest patch I submitted, which
also adds Exporter::ImportSpecs to turn the feature on, I can remove
Exporter::ImportSpecs and make it always-on if we decide to go that way
(which rjbs post implies to me that we will)

On Tue, Dec 22, 2015 at 8:27 AM, Chad Granum <exodist7@gmail.com> wrote:

> 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