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