Why Generators?

The biggest benefit of Sub::Exporter over existing exporters (including the ubiquitous Exporter.pm) is its ability to build new coderefs for export, rather than to simply export code identical to that found in the exporting package.

If your module's consumers get a routine that works like this:

  use Data::Analyze qw(analyze);
  my $value = analyze($data, $tolerance, $passes);

and they constantly pass only one or two different set of values for the non-$data arguments, your code can benefit from Sub::Exporter. By writing a simple generator, you can let them do this, instead:

  use Data::Analyze
    analyze => { tolerance => 0.10, passes => 10, -as => analyze10 },
    analyze => { tolerance => 0.15, passes => 50, -as => analyze50 };
  my $value = analyze10($data);

The package with the generator for that would look something like this:

  package Data::Analyze;
  use Sub::Exporter -setup => {
    exports => [
      analyze => \&build_analyzer,
    ],
  };
  sub build_analyzer {
    my ($class, $name, $arg) = @_;
    return sub {
      my $data      = shift;
      my $tolerance = shift || $arg->{tolerance}; 
      my $passes    = shift || $arg->{passes}; 
      analyze($data, $tolerance, $passes);
    }
  }

Your module's user now has to do less work to benefit from it -- and remember, you're often your own user! Investing in customized subroutines is an investment in future laziness.

This also avoids a common form of ugliness seen in many modules: package-level configuration. That is, you might have seen something like the above implemented like so:

  use Data::Analyze qw(analyze);
  $Data::Analyze::default_tolerance = 0.10;
  $Data::Analyze::default_passes    = 10;

This might save time, until you have multiple modules using Data::Analyze. Because there is only one global configuration, they step on each other's toes and your code begins to have mysterious errors.

Generators can also allow you to export class methods to be called as subroutines:

  package Data::Methodical;
  use Sub::Exporter -setup => { exports => { some_method => \&_curry_class } };
  sub _curry_class {
    my ($class, $name) = @_;
    sub { $class->$name(@_); };
  }

Because of the way that exporters and Sub::Exporter work, any package that inherits from Data::Methodical can inherit its exporter and override its "some_method". If a user imports "some_method" from that package, he'll receive a subroutine that calls the method on the subclass, rather than on Data::Methodical itself.

Other Customizations

Building custom routines with generators isn't the only way that Sub::Exporters allows the importing code to refine its use of the exported routines. They may also be renamed to avoid naming collisions.

Consider the following code:

  # this program determines to which circle of Hell you will be condemned
  use Morality qw(sin virtue); # for calculating viciousness
  use Math::Trig qw(:all);     # for dealing with circles

The programmer has inadvertently imported two "sin" routines. The solution, in Exporter.pm-based modules, would be to import only one and then call the other by its fully-qualified name. Alternately, the importer could write a routine that did so, or could mess about with typeglobs.

How much easier to write:

  # this program determines to which circle of Hell you will be condemned
  use Morality qw(virtue), sin => { -as => 'offense' };
  use Math::Trig -all => { -prefix => 'trig_' };

and to have at one's disposal "offense" and "trig_sin" -- not to mention "trig_cos" and "trig_tan".

Export Configuration

The "exports" list may be provided as an array reference or a hash reference. The list is processed in such a way that the following are equivalent:

  { exports => [ qw(foo bar baz), quux => \&quux_generator ] }
  { exports =>
    { foo => undef, bar => undef, baz => undef, quux => \&quux_generator } }

Generators are code that return coderefs. They are called with four parameters:

  $class - the class whose exporter has been called (the exporting class)
  $name  - the name of the export for which the routine is being build
 \%arg   - the arguments passed for this export
 \%col   - the collections for this import

Given the configuration in the "SYNOPSIS", the following "use" statement:

  use Text::Tweaker
    reformat => { -as => 'make_narrow', width => 33 },
    defaults => { eol => 'CR' };

would result in the following call to &build_reformatter:

  my $code = build_reformatter(
    'Text::Tweaker',
    'reformat',
    { width => 33 }, # note that -as is not passed in
    { defaults => { eol => 'CR' } },
  );

The returned coderef ($code) would then be installed as "make_narrow" in the calling package.

Instead of providing a coderef in the configuration, a reference to a method name may be provided. This method will then be called on the invocant of the "import" method. (In this case, we do not pass the $class parameter, as it would be redundant.)

Group Configuration

The "groups" list can be passed in the same forms as "exports". Groups must have values to be meaningful, which may either list exports that make up the group (optionally with arguments) or may provide a way to build the group.

The simpler case is the first: a group definition is a list of exports. Here's the example that could go in exporter in the "SYNOPSIS".

  groups  => {
    default    => [ qw(reformat) ],
    shorteners => [ qw(squish trim) ],
    email_safe => [
      'indent',
      reformat => { -as => 'email_format', width => 72 }
    ],
  },

Groups are imported by specifying their name prefixed be either a dash or a colon. This line of code would import the "shorteners" group:

  use Text::Tweaker qw(-shorteners);

Arguments passed to a group when importing are merged into the groups options and passed to any relevant generators. Groups can contain other groups, but looping group structures are ignored.

The other possible value for a group definition, a coderef, allows one generator to build several exportable routines simultaneously. This is useful when many routines must share enclosed lexical variables. The coderef must return a hash reference. The keys will be used as export names and the values are the subs that will be exported.

This example shows a simple use of the group generator.

  package Data::Crypto;
  use Sub::Exporter -setup => { groups => { cipher => \&build_cipher_group } };
  sub build_cipher_group {
    my ($class, $group, $arg) = @_;
    my ($encode, $decode) = build_codec($arg->{secret});
    return { cipher => $encode, decipher => $decode };
  }

The "cipher" and "decipher" routines are built in a group because they are built together by code which encloses their secret in their environment.

Default Groups

If a module that uses Sub::Exporter is "use"d with no arguments, it will try to export the group named "default". If that group has not been specifically configured, it will be empty, and nothing will happen.

Another group is also created if not defined: "all". The "all" group contains all the exports from the exports list.

Collector Configuration

The "collectors" entry in the exporter configuration gives names which, when found in the import call, have their values collected and passed to every generator.

For example, the "build_analyzer" generator that we saw above could be rewritten as:

 sub build_analyzer {
   my ($class, $name, $arg, $col) = @_;
   return sub {
     my $data      = shift;
     my $tolerance = shift || $arg->{tolerance} || $col->{defaults}{tolerance}; 
     my $passes    = shift || $arg->{passes}    || $col->{defaults}{passes}; 
     analyze($data, $tolerance, $passes);
   }
 }

That would allow the importer to specify global defaults for his imports:

  use Data::Analyze
    'analyze',
    analyze  => { tolerance => 0.10, -as => analyze10 },
    analyze  => { tolerance => 0.15, passes => 50, -as => analyze50 },
    defaults => { passes => 10 };
  my $A = analyze10($data);     # equivalent to analyze($data, 0.10, 10);
  my $C = analyze50($data);     # equivalent to analyze($data, 0.15, 50);
  my $B = analyze($data, 0.20); # equivalent to analyze($data, 0.20, 10);

If values are provided in the "collectors" list during exporter setup, they must be code references, and are used to validate the importer's values. The validator is called when the collection is found, and if it returns false, an exception is thrown. We could ensure that no one tries to set a global data default easily:

  collectors => { defaults => sub { return (exists $_[0]->{data}) ? 0 : 1 } }

Collector coderefs can also be used as hooks to perform arbitrary actions before anything is exported.

When the coderef is called, it is passed the value of the collection and a hashref containing the following entries:

  name        - the name of the collector
  config      - the exporter configuration (hashref)
  import_args - the arguments passed to the exporter, sans collections (aref)
  class       - the package on which the importer was called
  into        - the package into which exports will be exported

Collectors with all-caps names (that is, made up of underscore or capital A through Z) are reserved for special use. The only currently implemented special collector is "INIT", whose hook (if present in the exporter configuration) is always run before any other hook.

Special Exporter Arguments

The generated exporter accept some special options, which may be passed as the first argument, in a hashref.

These options are:

  into_level
  into
  generator
  installer

These override the same-named configuration options described in "EXPORTER CONFIGURATION".

setup_exporter

This routine builds and installs an "import" routine. It is called with one argument, a hashref containing the exporter configuration. Using this, it builds an exporter and installs it into the calling package with the name "import." In addition to the normal exporter configuration, a few named arguments may be passed in the hashref:

  into       - into what package should the exporter be installed
  into_level - into what level up the stack should the exporter be installed
  as         - what name should the installed exporter be given

By default the exporter is installed with the name "import" into the immediate caller of "setup_exporter". In other words, if your package calls "setup_exporter" without providing any of the three above arguments, it will have an "import" routine installed.

Providing both "into" and "into_level" will cause an exception to be thrown.

The exporter is built by "build_exporter".

build_exporter

Given a standard exporter configuration, this routine builds and returns an exporter -- that is, a subroutine that can be installed as a class method to perform exporting on request.

Usually, this method is called by "setup_exporter", which then installs the exporter as a package's import routine.

default_generator

This is Sub::Exporter's default generator. It takes bits of configuration that have been gathered during the import and turns them into a coderef that can be installed.

  my $code = default_generator(\%arg);

Passed arguments are:

  class - the class on which the import method was called
  name  - the name of the export being generated
  arg   - the arguments to the generator
  col   - the collections
  generator - the generator to be used to build the export (code or scalar ref)

default_installer

This is Sub::Exporter's default installer. It does what Sub::Exporter promises: it installs code into the target package.

  default_installer(\%arg, \@to_export);

Passed arguments are:

  into - the package into which exports should be delivered

@to_export is a list of name/value pairs. The default exporter assigns code (the values) to named slots (the names) in the given package. If the name is a scalar reference, the scalar reference is made to point to the code reference instead.