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. -- rjbsThread Previous | Thread Next