Re: Exporter in an OO module?

[haukex]

Hi SBECK,

If the two sets of subs (first set: OO methods like new, getters, setters, etc.; second set: exported functions, like constants) have no overlaps, there shouldn't be any problems. So for example, I would make sure none of my objects have a method named import and I would make sure to never export methods. As to whether it's a "best practice" I'm not sure, but I think that as long as all you're exporting are constants with unique, uppercased names, you probably wouldn't step on anyone's toes.

However, what I might do is use @EXPORT_OK instead of @EXPORT. You can group all your constants in a tag (%EXPORT_TAGS) named e.g. :constants. Your users will then have to write use Module::Name ':constants';, which has the advantage that it signals to the reader that it isn't just an OO module (which normally doesn't export anything), but is an OO package that also exports something. Plus, the user has the choice of not getting the constants, or only selecting the two or three constants they need.

As to how to make it "more OO", I'm not sure I have any good ideas off the top of my head. You could of course make your constants method calls,

use Module::Name;
my $c = Module::Name->new;
print $c->LOCALE_LANG_ALPHA_2;

but even though that'd keep the namespace clean of all the constants, personally I don't find this solution much more elegant.

Hope this helps,
-- Hauke D

[SBECK]

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;

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.

[haukex]

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