Front page | perl.perl5.porters |
Postings from December 2015
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