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:
Chad Granum
Date:
December 18, 2015 05:33
Subject:
Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm
Message ID:
CAJFr3kssy4QHC=6Nm2scdX=4SRExgO_HKiNbxMjzyBfQJYhxng@mail.gmail.com
The scratch package way is not completely universal. Sometimes the exporter
needs to inspect the destination in more detail. This is especially true
for things that use meta-objects associated with the destination obtained
through a method on the destination package. Import::Into exists because of
these other cases that a scratch package will not work with. This is why I
chose to make my implementation an extension of Import::Into.

In any case, a scratch package is still a complicated solution to the
problem. On the other hand a couple extra lines in Exporter.pm that make it
compatible with the feature in other exporters seems like a really simple
solution to the problem.

Yes you are right that all exporters would need to fall in line to truly
solve the problem, but I am not sure that is such a hard battle considering
the ones that already have this.

On Thu, Dec 17, 2015 at 9:22 PM, Zefram <zefram@fysh.org> wrote:

> Chad Granum wrote:
> >The problem is that it is very hard to do on the importing side. Once a
> sub
> >is entered into your namespace it is hard to undefine it.
>
> That would be a silly way to do it.  The sensible way is to first import
> into a scratch package (via the exporter, using standard names), then
> the import-side code can import from the scratch package into the caller
> package under a different name.  There's no conflict, and you don't undo
> anything (except for deleting the entire scratch package).  It's not hard.
> See Lexical::Import for how the scratch package thing operates.
>
> It's a bit inconvenient that the standard API for object exporting
> involves mutation of a package, and a package specified implicitly via
> caller() at that.  But it's a workable API, and its adoption is almost
> totally universal.  We should embrace the opportunity to use it to plug
> composable components together.
>
> -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