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;
[download]

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