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:
Zefram
Date:
December 21, 2015 00:26
Subject:
Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm
Message ID:
20151221002624.GO7818@fysh.org
Eirik Berg Hanssen wrote:
>  Only for sufficiently compliant exports, I suspect.

For exporters that insert their exports into the caller's package.
There are very few exporting modules that do anything not of that form.

>                                               You could alias the function
>without breaking anything, but how would you alias the scalar, so that the
>alias is also updated whenever the exported scalar is?

Aliasing a scalar is no problem.  *foo = \$bar.  Everything would work
absolutely straightforwardly if your module exported a scalar to which
it kept a reference, and then assigned to the exported scalar through
its reference.

What your module actually does is a little more complex: you keep a
reference to the *glob* into which you exported, and later assign to
the scalar referenced by that glob.  So this isn't a pure exporter:
it's reading back from the export target location, and will break
if the importer doesn't leave the scalar reference in that glob.
The renaming scheme involving importing into the wrong place and then
moving the item out would break this.  But the cleaner scheme with the
temporary package would work fine: you'd keep a reference to a glob in the
temporary package, thus keeping that glob alive past package deletion,
and everything would work because that glob is left intact.  You should
therefore find that Test::Trap works fine with Lexical::Import, which
puts the exported items into the importer's lexical namespace rather
than package.

I suggest that you should change Test::Trap to only keep a reference
to the scalar, to make it play more nicely.  It shouldn't make its
unwarranted assumptions about how the importer treats its globs
post-importatation.

>  How many other exporter strategies out there would this fail to account
>for, I wonder?

Anything that exports directly into the caller's lexical namespace
can't be munged by generic code working with packages.  Likewise any
other export that goes into a non-package namespace.  But those are
boring cases.  The only interesting cases would be modules that have a
more complex relationship with the caller's package, such as reading
from it or modifying it later than the nominal importation time.
It's difficult to generalise about these; one would have to look at
their specific reasons for this unusual behaviour.  Obviously, none of
these could be simply using Exporter's exporting logic.

-zefram

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