Codex

Sub::Exporter

Section: User Contributed Perl Documentation (3pm)

Updated: 2013-06-14

Index?action=index Return to Main Contents


NAME

Sub::Exporter - a sophisticated exporter for custom-built routines

VERSION

version 0.986

SYNOPSIS

Sub::Exporter must be used in two places. First, in an exporting module:

Then, in an importing module:

With this setup, the importing module ends up with three routines: , , and . The latter two have been built to the specifications of the importer --- they are not just copies of the code in the exporting package.

DESCRIPTION

ACHTUNG! If you're not familiar with Exporter or exporting, read Sub::Exporter::Tutorial first!

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:

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

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

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:

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:

Because of the way that exporters and Sub::Exporter work, any package that inherits from Data::Methodical can inherit its exporter and override its . If a user imports 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:

The programmer has inadvertently imported two 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:

and to have at one's disposal and --- not to mention and .

EXPORTER CONFIGURATION

You can configure an exporter for your package by using Sub::Exporter like so:

This is the simplest way to use the exporter, and is basically equivalent to this:

Any basic use of Sub::Exporter will look like this:

The following keys are valid in :

In addition to the basic options above, a few more advanced options may be passed:

In other words: Sub::Exporter installs a routine which, when called, exports routines to the calling namespace. The and options change where those exported routines are installed.
For information on how these callbacks are used, see the documentation for and .

Export Configuration

The 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:

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

Given the configuration in the ``SYNOPSIS'', the following statement:
would result in the following call to :
The returned coderef ( ) would then be installed as 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 method. (In this case, we do not pass the parameter, as it would be redundant.)

Group Configuration

The list can be passed in the same forms as . 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 are imported by specifying their name prefixed be either a dash or a colon. This line of code would import the group:

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.

The and 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 d with no arguments, it will try to export the group named . If that group has not been specifically configured, it will be empty, and nothing will happen.
Another group is also created if not defined: . The group contains all the exports from the exports list.

Collector Configuration

The 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 generator that we saw above could be rewritten as:

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

If values are provided in the 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:

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:

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 , whose hook (if present in the exporter configuration) is always run before any other hook.

CALLING THE EXPORTER

Arguments to the exporter (that is, the arguments after the module name in a statement) are parsed as follows:

First, the collectors gather any collections found in the arguments. Any reference type may be given as the value for a collector. For each collection given in the arguments, its validator (if any) is called.

Next, groups are expanded. If the group is implemented by a group generator, the generator is called. There are two special arguments which, if given to a group, have special meaning:

Finally, individual export generators are called and all subs, generated or otherwise, are installed in the calling package. There is only one special argument for export generators:

Normally, will contain an alternate name for the routine. It may, however, contain a reference to a scalar. If that is the case, a reference the generated routine will be placed in the scalar referenced by . It will not be installed into the calling package.

Special Exporter Arguments

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

These options are:

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

SUBROUTINES

setup_exporter

This routine builds and installs an 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:
By default the exporter is installed with the name into the immediate caller of . In other words, if your package calls without providing any of the three above arguments, it will have an routine installed.
Providing both and will cause an exception to be thrown.
The exporter is built by .

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 , 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.

Passed arguments are:

default_installer

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

Passed arguments are:

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.

EXPORTS

Sub::Exporter also offers its own exports: the and routines described above. It also provides a special ``setup'' collector, which will set up an exporter using the parameters passed to it.
Note that the ``setup collector (seen in examples like the ``SYNOPSIS above) uses , not . This means that the special arguments like ``into and ``as for are not accepted here. Instead, you may write something like:

Finding a good reason for wanting to do this is left as an exercise for the reader.

COMPARISONS

There are a whole mess of exporters on the CPAN. The features included in Sub::Exporter set it apart from any existing Exporter. Here's a summary of some other exporters and how they compare.

Exporter and co.

This is the standard Perl exporter. Its interface is a little clunky, but it's fast and ubiquitous. It can do some things that Sub::Exporter can't: it can export things other than routines, it can import ``everything in this group except this symbol,'' and some other more esoteric things. These features seem to go nearly entirely unused.

It always exports things exactly as they appear in the exporting module; it can't rename or customize routines. Its groups (``tags'') can't be nested.

Exporter::Lite is a whole lot like Exporter, but it does significantly less: it supports exporting symbols, but not groups, pattern matching, or negation.

The fact that Sub::Exporter can't export symbols other than subroutines is a good idea, not a missing feature.

For simple uses, setting up Sub::Exporter is about as easy as Exporter. For complex uses, Sub::Exporter makes hard things possible, which would not be possible with Exporter.

When using a module that uses Sub::Exporter, users familiar with Exporter will probably see no difference in the basics. These two lines do about the same thing in whether the exporting module uses Exporter or Sub::Exporter.

The definition for exporting in Exporter.pm might look like this:

Using Sub::Exporter, it would look like this:

Sub::Exporter respects inheritance, so that a package may export inherited routines, and will export the most inherited version. Exporting methods without currying away the invocant is a bad idea, but Sub::Exporter allows you to do just that --- and anyway, there are other uses for this feature, like packages of exported subroutines which use inheritance specifically to allow more specialized, but similar, packages.

Exporter::Easy provides a wrapper around the standard Exporter. It makes it simpler to build groups, but doesn't provide any more functionality. Because it is a front-end to Exporter, it will store your exporter's configuration in global package variables.

:

Attribute-Based Exporters

Some exporters use attributes to mark variables to export. Exporter::Simple supports exporting any kind of symbol, and supports groups. Using a module like Exporter or Sub::Exporter, it's easy to look at one place and see what is exported, but it's impossible to look at a variable definition and see whether it is exported by that alone. Exporter::Simple makes this trade in reverse: each variable's declaration includes its export definition, but there is no one place to look to find a manifest of exports.

More importantly, Exporter::Simple does not add any new features to those of Exporter. In fact, like Exporter::Easy, it is just a front-end to Exporter, so it ends up storing its configuration in global package variables. (This means that there is one place to look for your exporter's manifest, actually. You can inspect the package variables, and other related package variables, at runtime.)

Perl6::Export isn't actually attribute based, but looks similar. Its syntax is borrowed from Perl 6, and implemented by a source filter. It is a prototype of an interface that is still being designed. It should probably be avoided for production work. On the other hand, Perl6::Export::Attrs implements Perl 6-like exporting, but translates it into Perl 5 by providing attributes.

:

Other Exporters

Exporter::Renaming wraps the standard Exporter to allow it to export symbols with changed names.

Class::Exporter performs a special kind of routine generation, giving each importing package an instance of your class, and then exporting the instance's methods as normal routines. (Sub::Exporter, of course, can easily emulate this behavior, as shown above.)

Exporter::Tidy implements a form of renaming (using its argument) and of prefixing, and implements groups. It also avoids using package variables for its configuration.

:

TODO

write a set of longer, more demonstrative examples:
solidify the ``custom exporter'' interface (see ):
add an ``always'' group:

THANKS

Hans Dieter Pearcey provided helpful advice while I was writing Sub::Exporter. Ian Langworth and Shawn Sorichetti asked some good questions and helped me improve my documentation quite a bit. Yuval Kogman helped me find a bunch of little problems.

Thanks, guys!

BUGS

Please report any bugs or feature requests through the web interface at <http://rt.cpan.org>. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.

AUTHOR

Ricardo Signes <[email protected]>

COPYRIGHT AND LICENSE

This software is copyright (c) 2007 by Ricardo Signes.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.


Index

NAME

VERSION

SYNOPSIS

DESCRIPTION

Why Generators?

Other Customizations

EXPORTER CONFIGURATION

Export Configuration

Group Configuration

Collector Configuration

CALLING THE EXPORTER

Special Exporter Arguments

SUBROUTINES

setup_exporter

build_exporter

default_generator

default_installer

EXPORTS

COMPARISONS

TODO

THANKS

BUGS

AUTHOR

COPYRIGHT AND LICENSE