Re^2: Exporter in an OO module?

That does help, thanks.

The exported constants ARE all uppercase as in the example, and will never overlap the name of a function, so I'm safe there.

I hadn't considered the EXPORT_OK, but given that the OO interface is completely new, I don't mind requiring the users to specify that they want the constants.

Though if I do that, I could just as easily require the user to include:

   use Locale::Codes::Constants;
[download]

in their script. Then I avoid the necessity of exporting anything. Initially I was trying to avoid the user having to do anything special to access the constants (because they're automatically available with the traditional functional interface), but given that the OO interface is completely new, perhaps that's not a necessary, or even desirable, requirement.

Comment on Re^2: Exporter in an OO module? Download Code

Replies are listed 'Best First'.

Re^3: Exporter in an OO module?
by haukex (Archbishop) on Jan 04, 2017 at 16:58 UTC

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

[reply]
[d/l]
[select]


Perl: the Markov chain saw
	PerlMonks