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:
Ricardo Signes
Date:
December 22, 2015 00:12
Subject:
Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm
Message ID:
20151222001230.GC13040@cancer.codesimply.com
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