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.No module that uses Exporter actually does that. However, Exporter has a feature that says, "you, exporting module, the importer requests to import your default set of exports, do you have any?". Many people think this is "the exporting module exports without being asked", but that isn't true.
There are grasshoppers who think one should never have a non-empty @EXPORT. Those people are either clueless or just repeating others without actually using one of their own braincells. They don't seem to realize that if you prefer importers to list what they like to import:
is doesn't matter at all what the exporter has in @EXPORT.use Module1 (qw[sub1 sub2 sub3]); # Import three subs. use Module2 (); # Import nothing.
It's only when the importer writes:
that is, when the importer asks for defaults, you get what's in @EXPORT. And providing reasonable defaults, so reduce programmer load, that's good practice. Think about it. People complain they have to type use strict; over and over again. Would you have preferred strict not to have defaults, so you'd have to type use strict 'refs', 'vars', 'subs'; instead? Or would you want to list all the warnings classes you want to have enabled?use Module; # Import defaults.
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.See, that's the heart of the problem. People do not seem to realize that having an @EXPORT does not prevent you from listing what you want to import.
Good practice is to actually think, and decide what good defaults are for your module. Sometimes, the answer is "no defaults". Far more often it makes sense to provide a non-empty set of defaults. Having defaults robs the user of nothing; having defaults optimizes for the common case.
And again, as OO modules use referential notation, and don't export anything, there's no namespace pollution.OO modules are actually worse. You cannot control what your parent class "exports". Sure, it's not taking a slot in the stash of your package, but with OO, dispatch isn't just done in your package (as with non-OO code), but it's searched through the entire @ISA tree. If you do our @ISA = qw[Module], your objects will have any subroutine defined in Module as a method; and no control is provided which methods you want or not. You'd need a set of tiny partial classes, which you then mix-and-match using MI (or roles, but roles are just MI without using the word MI). Of course, then you're back to the same problems you mentioned before, from which class did we inherit method, or what if we want to use two roles that both use methods with the same name? Note also that if you import a subroutine with the same name as a subroutine you already have, or if you import subroutines with the same name from different namespaces, a warning is generated (assuming you have warnings turned on). That doesn't happen with OO. Perl won't tell you you're inheriting two identical named methods. Or that one of your methods is masking one in your parent class.
In reply to Re^2: "I Only Wanted a Hammer, Not the Whole Toolbox."
by JavaFan
in thread "I Only Wanted a Hammer, Not the Whole Toolbox."
by luis.roca
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |