Module Design and Implementation

then client code will have to list their imports explicitly. Using a module that 

exports with @EXPORT_OK won't trigger any unwanted namespace pollution.

The Exporter also supports a more advanced mechanism for managing your 

exported symbols: tags. By setting up export tags, you create shortcuts to importing a 

group of symbols. This is particularly helpful for large modules with many symbols 

to export. For example, here's a version of BOA::Network that sets up three tags 

all, client, and server:

package BOA::Network;

require Exporter;

@ISA = qw(Exporter);

@EXPORT_OK = qw(open_socket

                send_message

                receive_message

                close_socket

                start_server

                stop_server);

%EXPORT_TAGS = (

                 all    => [ @EXPORT_OK ],

                 client => [ qw(open_socket

                                send_message

                                close_socket) ],

                 server => [ qw(start_server

                                receive_message

                                stop_server) ],

                );

Now a user of the module can use a tag when they use BOA::Network and automat 

ically pull in a set of symbols:

use BOA::Network qw(:client);

It's worth noting that using %EXPORT_TAGS has many of the same problems that 

using @EXPORT does. Debugging is just as difficult without an obvious source for 

each symbol, and an upgrade that adds a symbol to an existing tag can cause unex 

pected collisions. As a general rule, you should use @EXPORT_OK whenever you can 

and only resort to %EXPORT_TAGS for truly large modules.

81

81