[Israel.pm] OO Perl and Exporter

Uri Bruck 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 mailing list