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