Just to be clear, posting the patches here for review and commentary before updating my p5p rt ticket with them. On Dec 20, 2015 10:53 PM, "Chad Granum" <exodist7@gmail.com> wrote: > Here are 2 new patches. The first is a simple whitespace fix that I made a > separate commit. I don't care if it should be tabs or spaces, but I think > most people agree a file should pick one and stick to it. I can drop the > commit and re-make the second without the whitespace changes if changing > them is taboo. I can also switch the indentation to tabs instead of spaces > if that is preferred. I was just annoyed having both littered, often on the > same line for the same indentation. > > The second commit is the addition of the feature, taking into account much > of the feedback from this thread. Both these patches are based directly off > of blead, not off my last patch. > > Things updated/altered: > * Works predictably when combined with tags and other advanced features > * Have to use Exporter::ImportSpecs in the importing class in order to > enable the behavior > * Warnings for unknown keys in the specification > > I picked the name Exporter::ImportSpecs instead of Exporter::Rename since > one of the benefits of the symbol => { ... } form was that it is extendable > if needed. Naming the package that enables the specification of the hash > after a specific feature of the hash seemed short-sighted. That said I do > not love the name and welcome bike-shedding for a better one. > > -Chad > > On Thu, Dec 17, 2015 at 12:51 PM, Chad Granum <exodist7@gmail.com> wrote: > >> Several modern export tools such as Sub::Exporter and Exporter::Declare >> make it possible to rename subs that you import. They tend to use a >> consistent syntax: >> >> use Foo 'export_name' => {-as => 'new_name'}; >> >> >> As of yet Exporter.pm has no such capability. >> >> 1) Would anyone be opposed to having this functionality added? (and why?) >> 2) Does anyone oppose keeping the above syntax since it is consistent >> with everything else? >> 3) Are there any good technical reasons not to do this? >> >> Assuming there are no objections to the idea I would like to write a >> patch (unless someone else wants to do it). >> >> -Chad >> > >Thread Previous | Thread Next