[Israel.pm] OO Perl and Exporter
bruck at actcom.net.il
Tue Dec 28 14:07:18 PST 2004
Offer Kaye wrote:
> So getting back to _my_ original question - is there any valid reason
> to use Exporter in a pure, OO module?
One thing you can do is look at existing modules, see what they do, and
try to guess the reason the programmers had for exporting, either by
default or by request.
DBI, for example, exports nothing by default. This makes a lot of sense
to me. You can use DBI to connect to several databases, and almost any
action you take is an action on a specific database. Saying :
do ("select * from myTable")
doesn't mean anything unless you specify which database you act on, and
you do by calling the method on the database handle you created earlier.
You use these methods within a context.
SOAP::Lite, OTOH, exports by default quite a lot. SOAP::Lite, whether
you use it to implement the server side or the client side of a web
service, is there to help you communicate with programs that come from
other cultures, or rather with a common culture. Making the vocabulary
of that culture your own seems like a sensible thing to do.
CPAN module also exports a lot by default. But then CPAN is a module
with a very specific purpose. In a way this module is its own context.
You can still use EXPORT and EXPORT_OK to tell the programmers using
your module that there are some methods that you think will be so useful
for them that they will want to import them, and think of them as
functions available to them within their context.
As for me, I like to have as much control as possible over what's in my
namespaces, just as I like to have control as to who let in to my home.
More information about the Perl