For some background on the principles behind the LanX's excellent points, see Information hiding -- the general idea is to hide your module's implementation (which is likely to change over time) from the (possibly many) programs that call it. So don't just blindly export all your module's variables! Instead, think harder about designing a good module interface, one that will stand the test of time, and so allow you to make many future module improvements without needing to update in step all your programs that use it.

This topic is discussed in much more detail at: On Interfaces and APIs

As long as you don't make it too hard to modify the behaviour of your code, that is. Also see the discussion on How to redefine a modules private function?.

perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'

Also related is TDD because writing a test first forces you to focus on module interface early and from the point of view of the module user.

In your example discussion, module tests that employed a mock DNS server running on a different port would have caught this specific module interface issue before the module was released. Not only that, having your own mock DNS server controlled by your tests makes it easier to test module robustness and recovery (for example, how your module handles timeouts, broken connections, data corruption, ...).

Yes indeed! An example of having to resort to mind-boggling trickery and deviousness simply to modify the default value of a module parameter! :) While entertaining, and a challenging problem, definitely not an example of good module design.

From On Interfaces and APIs, the most relevant point is probably this simple tip for Perl module designers from TheDamian:

• Make common usage the default; allow uncommon usage via optional attributes.

In fact, it is probably better to make the variables lexical (i.e. 'my' rather than 'our'). The 'our' variables are still accessible using their fully-qualified names. The 'my' variables are not accessible at all from outside the scope that declares them, unless some code in that scope passes them out.

Yes, in general one is better off to
• always default to private vars with my
• only use public our when really needed

But this is not always so, there are always exceptions to the rule.

Some modules use package vars for external config, e.g. Text::Glob or Data::Dumper °

Some even export readonly vars to be used as constants (instead of barewords without sigils)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

°) of course TIMTOWTDI, these design patterns date back to the Perl4 times, which had neither OOP nor private lexical vars. Data::Dumper for instance has a dual API.

The 'my' variables are not accessible at all from outside the scope that declares them, unless some code in that scope passes them out.

PadWalker