Hi SBECK,
Initially I was trying to avoid the user having to do anything special to access the constants
I was first introduced to the idea that @EXPORTing a bunch of stuff might not be a good idea by the Perl::Critic policy "ProhibitAutomaticExportation", and have since come to mostly agree with that idea, at least to minimize automatic exportation. Quoting the module's doc:
When using Exporter, symbols placed in the @EXPORT variable are automatically exported into the caller's namespace. Although convenient, this practice is not polite, and may cause serious problems if the caller declares the same symbols. The best practice is to place your symbols in @EXPORT_OK or %EXPORT_TAGS and let the caller choose exactly which symbols to export.
My take on it is this: What does the user expect will happen when they write use Module::Name;? If the module is an OO module, the user might not expect it to export anything, so that should probably be its default behavior. However, in the case of use Locale::Codes::Constants;, the name implies that it's a module of constants, so perhaps exporting a default set of constants is a useful default behavior. I've also had in-between cases, like e.g. a module that has one central function, which I decided to export by default, but the other functions in the module had to be exported explicitly. Some more questions one might ask oneself when deciding: how much do we want to pollute the user's namespace, which of the functions will they always need, and which only sometimes? Sometimes it's hard to decide on a default behavior, but in those cases I don't think it really hurts to just keep @EXPORT empty, at least in the first version of the module.
Regards,
-- Hauke D
In reply to Re^3: Exporter in an OO module?
by haukex
in thread Exporter in an OO module?
by SBECK
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |