Let's look at what's actually going on when a module exports a subroutine. Say, for example, that in module Foo there is a sub named 'bar'. You use Foo, and Foo exports 'bar' to the caller's namespace. If package main used 'Foo', then Foo will export bar() to main. The way it does this is by assigning \&bar to *main::bar. Symbol table manipulation.
Now main:: has a subroutine named bar(), which happens to be the same piece of code as the one originally called Foo::bar(). Both names are an alias to the same function.
The problem when a module does this without being asked is that of namespace pollution, and namespace conflicts. LWP::Simple exports get(). Maybe some other module also exports get(). You can't have two gets in package main. Conflict. Modules that export without being asked to are the worst perpetrators because they may export several names into your namespace and it's up to you to read the docs and figure out what they're doing to you. If every module did that we would have all sorts of interoperability problems due to name collisions.
Fortunately most modules that export allow you to specify exactly what you want to import into the calling namespace. List::Util is such a module. You have to tell it explicitly that you want max(). That's good, because then if you also want to use some other module that has a max() you can decide which module's max you will import, and which you will invoke by fully qualified name.
I would say that whether or not a module automatically exports, it's never a bad thing to enumerate on the 'use' line what it is that you wish to import from the module. It may seem pointless to specify use File::Find qw/find/; when we know that File::Find already automatically exports find(). But someday you may look at your code again; the code that uses six modules... and you'll have a hard time remembering where find() is coming from. Enumerate it on the use line, and it's easy to look at the code and recall, "Oh, find() is from File::Find, not from My::Lost::Keys::find()."
Another reason to specify what you want to import is that many of the modules that export do use @EXPORT_OK rather than @EXPORT, which means that you the user get to decide what you want to bring into the calling namespace.
There's another nice trick too. If you call use My::Module ();, by specifying an empty import list the module's import() function will not be invoked, and the module will export nothing to the caller's namespace. use File::Find (); find(); will complain that &main::Find is undefined. See? We just prevented File::Find from polluting our namespace. We can still invoke find() by using its fully qualified name: File::Find::find().
Now for OO modules. Those modules don't typically export anything. There are exceptions, such as CGI.pm which has both a function and a OO interface, but most OO modules keep things pretty clean (we hope). That being the case, there's no need or benefit to specifying an import list on the use line. In fact, even the reason I gave earlier of being able to look at code and know where the sub is coming from no longer applies, since OO modules use referential notation to access the methods. Module->method(), $class->method(), $object->method(). All we have to do is look to the left of the -> to know who owns the method (inheritance nightmares notwithstanding).
And again, as OO modules use referential notation, and don't export anything, there's no namespace pollution. There's no good reason to say, "Well, I need Math::Matrix, but the only sub I need from it is multiply()." Doesn't matter. The other functions are built into its api, but they just sit there in case you need them. They're not being brought into your caller's namespace. They're not hurting anything really.
I chimed in here to try to clarify some of the points I was making in the CB. I know another person or two were working along other points as well; one issue was why Exporter doesn't throw a fatal when someone specifies an import list on an OO module that doesn't export anything (it ought to, but doesn't being the assertion).
I hope some of this is helpful, and even more, I hope that most of it is accurate and coherent. ;)
Dave
In reply to Re: "I Only Wanted a Hammer, Not the Whole Toolbox."
by davido
in thread "I Only Wanted a Hammer, Not the Whole Toolbox."
by luis.roca
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |