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