|
SBECK has asked for the wisdom of the Perl Monks concerning the following question:
I maintain the perl distribution Locale-Codes, and when I took
over it, I inherited a number practices that I maintain for
backward compatibility.
One of the things that the modules do is that they export a
number of perl constants that can be used to specify exactly what
code set you want to work with. So, when working with languages,
the language module includes:
use Locale::Codes::Constants;
our(@ISA,@EXPORT);
@ISA = qw(Exporter);
@EXPORT = qw(LOCALE_LANG_ALPHA_2);
I just added an object-oriented interface to the distribution, and I want to be able
to specify the code set in the methods by using the constants (to be as similar to the traditional functions as possible).
I added the above lines to the OO module, and everything worked as desired,
so I could just go ahead and leave it there, but it seems a bit wrong to
export stuff in an OO module where typically everything is available via.
a method.
Nothing is exported except for the constants, so is this generally considered
an acceptable practice? Is there a better (i.e. more OO way) to make the constants available?
|
Re: Exporter in an OO module?
by ikegami (Patriarch) on Jan 04, 2017 at 16:08 UTC
|
That's perfectly fine, although that's a rather archaic usage of Exporter.
use Locale::Codes::Constants;
use Exporter qw( import );
our @EXPORT = qw( LOCALE_LANG_ALPHA_2 );
| [reply]
[d/l] |
|
|
that's a rather archaic usage of Exporter
How should anyone know better? The documentation of Exporter has not been changed much (diff) in the last six years, all of the problems I wrote about six years ago still exist, starting with the archaic example using require and @ISA = qw(Exporter). Almost all examples still inherit from Exporter, and only half way down through the documentation a single example shows that you don't have to inherit from Exporter. Inheriting from Exporter is still shown as "good practice". Even worse, the documentation shows how to use base or parent to inherit from Exporter. And don't make me think about the recommended Exporter::Easy, hiding the unneeded inheritance in yet another module.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l] |
Re: Exporter in an OO module?
by haukex (Archbishop) on Jan 04, 2017 at 15:54 UTC
|
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 | [reply]
[d/l]
[select] |
|
|
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.
| [reply]
[d/l] |
|
|
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] |
Re: Exporter in an OO module for CONSTANTS? Lexical?
by Anonymous Monk on Jan 05, 2017 at 01:32 UTC
|
How many constants would a typical program use?
I say forget about exporting and make them type out the full name, one of these, whatever makes sense to you
Locale::CODE_DOM()
Locale::LOCALE_CODE_DOM()
c::LOCALE_CODE_DOM()
Otherwise I suggest something like Exporter::Lexical over plain old Exporter
| [reply]
[d/l] |
|
|
