Exporter::Tiny - an exporter with the features of Sub::Exporter but only core dependencies |
Exporter::Tiny - an exporter with the features of Sub::Exporter but only core dependencies
package MyUtils; use base "Exporter::Tiny"; our @EXPORT = qw(frobnicate); sub frobnicate { my $n = shift; ... } 1;
package MyScript; use MyUtils "frobnicate" => { -as => "frob" }; print frob(42); exit;
Exporter::Tiny supports many of Sub::Exporter's external-facing features
including renaming imported functions with the -as
, -prefix
and
-suffix
options; explicit destinations with the into
option;
and alternative installers with the installler
option. But it's written
in only about 40% as many lines of code and with zero non-core dependencies.
Its internal-facing interface is closer to Exporter.pm, with configuration
done through the @EXPORT
, @EXPORT_OK
and %EXPORT_TAGS
package variables.
Exporter::Tiny performs most of its internal duties (including resolution of tag names to sub names, resolution of sub names to coderefs, and installation of coderefs into the target package) as method calls, which means they can be overridden to provide interesting behaviour.
These are really for internal use, but can be exported if you need them.
mkopt(\@array)
mkopt
from the Data::OptList manpage. It doesn't support all the
fancy options that Data::OptList does (moniker
, require_unique
,
must_be
and name_test
) but runs about 50% faster.
mkopt_hash(\@array)
mkopt_hash
from the Data::OptList manpage. See also mkopt
.
For the purposes of this discussion we'll assume we have a module called
MyUtils
which exports one function, frobnicate
. MyUtils
inherits from Exporter::Tiny.
Many of these tricks may seem familiar from the Sub::Exporter manpage. That is intentional. Exporter::Tiny doesn't attempt to provide every feature of Sub::Exporter, but where it does it usually uses a fairly similar API.
# import "frobnicate" function use MyUtils "frobnicate";
# import all functions that MyUtils offers use MyUtils -all;
# call it "frob" use MyUtils "frobnicate" => { -as => "frob" };
# call it "my_frobnicate" use MyUtils "frobnicate" => { -prefix => "my_" };
# can set a prefix for *all* functions imported from MyUtils # by placing the options hashref *first*. use MyUtils { prefix => "my_" }, "frobnicate"; # (note the lack of hyphen before `prefix`.)
# call it "frobnicate_util" use MyUtils "frobnicate" => { -suffix => "_util" }; use MyUtils { suffix => "_util" }, "frobnicate";
# import it twice with two different names use MyUtils "frobnicate" => { -as => "frob" }, "frobnicate" => { -as => "frbnct" };
{ use Sub::Exporter::Lexical lexical_installer => { -as => "lex" }; use MyUtils { installer => lex }, "frobnicate"; frobnicate(...); # ok } frobnicate(...); # not ok
use MyUtils { into => "OtherPkg" }, "frobnicate"; OtherPkg::frobincate(...);
my $func; use MyUtils "frobnicate" => { -as => \$func }; $func->(...);
OK, Sub::Exporter doesn't do this...
my %funcs; use MyUtils { into => \%funcs }, "frobnicate"; $funcs{frobnicate}->(...);
This imports everything except ``frobnicate'':
use MyUtils qw( -all !frobnicate );
Negated imports always ``win'', so the following will not import ``frobnicate'', no matter how many times you repeat it...
use MyUtils qw( !frobnicate frobnicate frobnicate frobnicate );
Here's how you could import all functions beginning with an ``f'':
use MyUtils qw( /^F/i );
Or import everything except functions beginning with a ``z'':
use MyUtils qw( -all !/^Z/i );
Note that regexps are always supplied as strings starting with
"/"
, and not as quoted regexp references (qr/.../
).
You can unimport the functions that MyUtils added to your namespace:
no MyUtils;
Or just specific ones:
no MyUtils qw(frobnicate);
If you renamed a function when you imported it, you should unimport by the new name:
use MyUtils frobnicate => { -as => "frob" }; ...; no MyUtils "frob";
Unimporting using tags and regexps should mostly do what you want.
Simple configuration works the same as Exporter; inherit from this module,
and use the @EXPORT
, @EXPORT_OK
and %EXPORT_TAGS
package variables to list subs to export.
Exporter::Tiny has always allowed exported subs to be generated (like the Sub::Exporter manpage), but until version 0.025 did not have an especially nice API for it.
Now, it's easy. If you want to generate a sub foo
to export, list it in
@EXPORT
or @EXPORT_OK
as usual, and then simply give your
exporter module a class method called _generate_foo
.
push @EXPORT_OK, 'foo'; sub _generate_foo { my $class = shift; my ($name, $args, $globals) = @_; return sub { ...; } }
You can also generate tags:
my %constants; BEGIN { %constants = (FOO => 1, BAR => 2); } use constant \%constants; $EXPORT_TAGS{constants} = sub { my $class = shift; my ($name, $args, $globals) = @_; return keys(%constants); };
An important difference between Exporter and Exporter::Tiny is that the latter calls all its internal functions as class methods >. This means that your subclass can override them > to alter their behaviour.
The following methods are available to be overridden. Despite being named with a leading underscore, they are considered public methods. (The underscore is there to avoid accidentally colliding with any of your own function names.)
_exporter_validate_opts($globals)
import
is called. It is passed a
reference to the global options hash. (That is, the optional leading hashref
in the use
statement, where the into
and installer
options can be
provided.)
You may use this method to munge the global options, or validate them, throwing an exception or printing a warning.
The default implementation does nothing interesting.
_exporter_validate_unimport_opts($globals)
_exporter_validate_opts
, but called for unimport
.
_exporter_merge_opts($tag_opts, $globals, @exports)
_exporter_expand_tag($name, $args, $globals)
":constants"
).
It is passed the tag name (minus the leading ``:''), an optional hashref
of options (like { -prefix => "foo_" }
), and the global options
hashref.
It is expected to return a list of ($name, $args) arrayref pairs. These names can be sub names to export, or further tag names (which must have their ``:''). If returning tag names, be careful to avoid creating a tag expansion loop!
The default implementation uses %EXPORT_TAGS
to expand tags, and
provides fallbacks for the :default
and :all
tags.
_exporter_expand_regexp($regexp, $args, $globals)
_exporter_expand_regexp
, but given a regexp-like string instead
of a tag name.
The default implementation greps through @EXPORT_OK
for imports,
and the list of already-imported functions for exports.
_exporter_expand_sub($name, $args, $globals)
"+Foo"
gets expanded to:
( Foo => sub { $type }, is_Foo => sub { $type->check(@_) }, to_Foo => sub { $type->assert_coerce(@_) }, assert_Foo => sub { $type->assert_return(@_) }, )
The default implementation checks that the name is allowed to be exported
(using the _exporter_permitted_regexp
method), gets the coderef using
the generator if there is one (or by calling can
on your exporter
otherwise) and calls _exporter_fail
if it's unable to generate or
retrieve a coderef.
_exporter_permitted_regexp($globals)
_exporter_expand_sub
will refuse to export it. (Of
course, you may override the default _exporter_expand_sub
.)
The default implementation of this method assembles the regexp from
@EXPORT
and @EXPORT_OK
.
_exporter_fail($name, $args, $globals)
_exporter_expand_sub
if it can't find a coderef to export.
The default implementation just throws an exception. But you could emit a warning instead, or just ignore the failed export.
If you don't throw an exception then you should be aware that this
method is called in list context, and any list it returns will be treated
as an _exporter_expand_sub
-style hash of names and coderefs for
export.
_exporter_install_sub($name, $args, $globals, $coderef)
The default implementation handles sub renaming (i.e. the -as
,
-prefix
and -suffix
functions. This method does a lot of
stuff; if you need to override it, it's probably a good idea to just
pre-process the arguments and then call the super method rather than
trying to handle all of it yourself.
_exporter_uninstall_sub($name, $args, $globals)
_exporter_install_sub
.
use MyUtils { replace => 1 }, "frobnicate"; use MyUtils "frobnicate" => { -replace => 1 };
Or can be upgraded to a fatal error:
use MyUtils { replace => "die" }, "frobnicate"; use MyUtils "frobnicate" => { -replace => "die" };
-prefix
or -suffix
.
the Type::Library manpage had a bunch of custom exporting code which poked coderefs into its caller's stash. It needed this to be something more powerful than most exporters so that it could switch between exporting Moose, Mouse and Moo-compatible objects on request. the Sub::Exporter manpage would have been capable, but had too many dependencies for the Type::Tiny project.
Meanwhile the Type::Utils manpage, the Types::TypeTiny manpage and the Test::TypeTiny manpage each used the venerable Exporter.pm. However, this meant they were unable to use the features like the Sub::Exporter manpage-style function renaming which I'd built into Type::Library:
## import "Str" but rename it to "String". use Types::Standard "Str" => { -as => "String" };
And so I decided to factor out code that could be shared by all Type-Tiny's exporters into a single place: Exporter::TypeTiny.
As of version 0.026, Exporter::TypeTiny was also made available as the Exporter::Tiny manpage, distributed independently on CPAN. CHOCOLATEBOY had convinced me that it was mature enough to live a life of its own.
As of version 0.030, Type-Tiny depends on Exporter::Tiny and Exporter::TypeTiny is being phased out.
Exporting is unlikely to be your application's performance bottleneck, but nonetheless here are some comparisons.
Comparative sizes according to the Devel::SizeMe manpage: >
Exporter 217.1Kb Sub::Exporter::Progressive 263.2Kb Exporter::Tiny 267.7Kb Exporter + Exporter::Heavy 281.5Kb Exporter::Renaming 406.2Kb Sub::Exporter 701.0Kb
Performance exporting a single sub: >
Rate SubExp ExpTiny SubExpProg ExpPM SubExp 2489/s -- -56% -85% -88% ExpTiny 5635/s 126% -- -67% -72% SubExpProg 16905/s 579% 200% -- -16% ExpPM 20097/s 707% 257% 19% --
(Exporter::Renaming globally changes the behaviour of Exporter.pm, so could not be included in the same benchmarks.)
(Non-Core) Dependencies: >
Exporter -1 Exporter::Renaming 0 Exporter::Tiny 0 Sub::Exporter::Progressive 0 Sub::Exporter 3
Features: >
ExpPM ExpTiny SubExp SubExpProg Can export code symbols............. Yes Yes Yes Yes Can export non-code symbols......... Yes Groups/tags......................... Yes Yes Yes Yes Export by regexp.................... Yes Yes Bang prefix......................... Yes Yes Allows renaming of subs............. Yes Yes Maybe Install code into scalar refs....... Yes Yes Maybe Can be passed an "into" parameter... Yes Yes Maybe Can be passed an "installer" sub.... Yes Yes Maybe Config avoids package variables..... Yes Supports generators................. Yes Yes Sane API for generators............. Yes Yes Unimport............................ Yes
(Certain Sub::Exporter::Progressive features are only available if Sub::Exporter is installed.)
Please report any bugs to http://rt.cpan.org/Dist/Display.html.
IRC: > support is available through in the #moops > channel on irc.perl.org.
the Exporter::Shiny manpage, the Sub::Exporter manpage, Exporter.
Toby Inkster <tobyink@cpan.org>.
This software is copyright (c) 2013-2014 by Toby Inkster.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Exporter::Tiny - an exporter with the features of Sub::Exporter but only core dependencies |