X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FExporter.pm;h=753ea6aab271185a2bde18adb55d10ba2174d05b;hb=70ee44090a3faf48295f65df1a1fe1c53d04be10;hp=00010892faaa92c1759922bcc350d66fe1b7521c;hpb=d584343b7f3430eea5d5ee3fa63a1efa814c98a0;p=p5sagit%2Fp5-mst-13.2.git diff --git a/lib/Exporter.pm b/lib/Exporter.pm index 0001089..753ea6a 100644 --- a/lib/Exporter.pm +++ b/lib/Exporter.pm @@ -2,33 +2,28 @@ package Exporter; require 5.006; -use strict; -no strict 'refs'; +# Be lean. +#use strict; +#no strict 'refs'; our $Debug = 0; our $ExportLevel = 0; our $Verbose ||= 0; -our $VERSION = '5.565'; +our $VERSION = '5.567'; +our (%Cache); $Carp::Internal{Exporter} = 1; -sub export_to_level { +sub as_heavy { require Exporter::Heavy; - goto &Exporter::Heavy::heavy_export_to_level; + # Unfortunately, this does not work if the caller is aliased as *name = \&foo + # Thus the need to create a lot of identical subroutines + my $c = (caller(1))[3]; + $c =~ s/.*:://; + \&{"Exporter::Heavy::heavy_$c"}; } sub export { - require Exporter::Heavy; - goto &Exporter::Heavy::heavy_export; -} - -sub export_tags { - require Exporter::Heavy; - Exporter::Heavy::_push_tags((caller)[0], "EXPORT", \@_); -} - -sub export_ok_tags { - require Exporter::Heavy; - Exporter::Heavy::_push_tags((caller)[0], "EXPORT_OK", \@_); + goto &{as_heavy()}; } sub import { @@ -36,10 +31,10 @@ sub import { my $callpkg = caller($ExportLevel); # We *need* to treat @{"$pkg\::EXPORT_FAIL"} since Carp uses it :-( - my($exports, $export_cache, $fail) - = (\@{"$pkg\::EXPORT"}, \%{"$pkg\::EXPORT"}, \@{"$pkg\::EXPORT_FAIL"}); + my($exports, $fail) = (\@{"$pkg\::EXPORT"}, \@{"$pkg\::EXPORT_FAIL"}); return export $pkg, $callpkg, @_ if $Verbose or $Debug or @$fail > 1; + my $export_cache = ($Cache{$pkg} ||= {}); my $args = @_ or @_ = @$exports; local $_; @@ -65,7 +60,6 @@ sub import { *{"$callpkg\::$_"} = \&{"$pkg\::$_"} foreach @_; } - # Default methods sub export_fail { @@ -73,12 +67,25 @@ sub export_fail { @_; } +# Unfortunately, caller(1)[3] "does not work" if the caller is aliased as +# *name = \&foo. Thus the need to create a lot of identical subroutines +# Otherwise we could have aliased them to export(). -sub require_version { - require Exporter::Heavy; - goto &Exporter::Heavy::require_version; +sub export_to_level { + goto &{as_heavy()}; +} + +sub export_tags { + goto &{as_heavy()}; } +sub export_ok_tags { + goto &{as_heavy()}; +} + +sub require_version { + goto &{as_heavy()}; +} 1; __END__ @@ -89,28 +96,25 @@ Exporter - Implements default import method for modules =head1 SYNOPSIS -In module ModuleName.pm: +In module YourModule.pm: - package ModuleName; + package YourModule; require Exporter; @ISA = qw(Exporter); + @EXPORT_OK = qw(munge frobnicate); # symbols to export on request - @EXPORT = qw(...); # symbols to export by default - @EXPORT_OK = qw(...); # symbols to export on request - %EXPORT_TAGS = tag => [...]; # define names for sets of symbols - -In other files which wish to use ModuleName: - - use ModuleName; # import default symbols into my package +In other files which wish to use YourModule: - use ModuleName qw(...); # import listed symbols into my package - - use ModuleName (); # do not import any symbols + use ModuleName qw(frobnicate); # import listed symbols + frobnicate ($left, $right) # calls YourModule::frobnicate =head1 DESCRIPTION -The Exporter module implements a default C method which -many modules choose to inherit rather than implement their own. +The Exporter module implements an C method which allows a module +to export functions and variables to its users' namespaces. Many modules +use Exporter rather than implementing their own C method because +Exporter provides a highly flexible interface, with an implementation optimised +for the common case. Perl automatically calls the C method when processing a C statement for a module. Modules and C are documented @@ -130,6 +134,9 @@ ampersand in front of a function is optional, e.g. @EXPORT = qw(afunc $scalar @array); # afunc is a function @EXPORT_OK = qw(&bfunc %hash *typeglob); # explicit prefix on &bfunc +If you are only exporting function names it is recommended to omit the +ampersand, as the implementation is faster this way. + =head2 Selecting What To Export Do B export method names! @@ -156,10 +163,42 @@ how to make inheritance work.) As a general rule, if the module is trying to be object oriented then export nothing. If it's just a collection of functions then -@EXPORT_OK anything but use @EXPORT with caution. +@EXPORT_OK anything but use @EXPORT with caution. For function and +method names use barewords in preference to names prefixed with +ampersands for the export lists. Other module design guidelines can be found in L. +=head2 How to Import + +In other files which wish to use your module there are three basic ways for +them to load your module and import its symbols: + +=over 4 + +=item C + +This imports all the symbols from ModuleName's @EXPORT into the namespace +of the C statement. + +=item C + +This causes perl to load your module but does not import any symbols. + +=item C + +This imports only the symbols listed by the caller into their namespace. +All listed symbols must be in your @EXPORT or @EXPORT_OK, else an error +occurs. The advanced export features of Exporter are accessed like this, +but with list entries that are syntactically distinct from symbol names. + +=back + +Unless you want to use its advanced features, this is probably all you +need to know to use Exporter. + +=head1 Advanced features + =head2 Specialised Import Lists If the first entry in an import list begins with !, : or / then the @@ -203,13 +242,13 @@ You can say C to see how the specifications are being processed and what is actually being imported into modules. -=head2 Exporting without using Export's import method +=head2 Exporting without using Exporter's import method Exporter has a special method, 'export_to_level' which is used in situations -where you can't directly call Export's import method. The export_to_level +where you can't directly call Exporter's import method. The export_to_level method looks like: -MyPackage->export_to_level($where_to_export, $package, @what_to_export); + MyPackage->export_to_level($where_to_export, $package, @what_to_export); where $where_to_export is an integer telling how far up the calling stack to export your symbols, and @what_to_export is an array telling what @@ -219,30 +258,30 @@ currently unused. For example, suppose that you have a module, A, which already has an import function: -package A; + package A; -@ISA = qw(Exporter); -@EXPORT_OK = qw ($b); + @ISA = qw(Exporter); + @EXPORT_OK = qw ($b); -sub import -{ - $A::b = 1; # not a very useful import method -} + sub import + { + $A::b = 1; # not a very useful import method + } and you want to Export symbol $A::b back to the module that called package A. Since Exporter relies on the import method to work, via inheritance, as it stands Exporter::import() will never get called. Instead, say the following: -package A; -@ISA = qw(Exporter); -@EXPORT_OK = qw ($b); + package A; + @ISA = qw(Exporter); + @EXPORT_OK = qw ($b); -sub import -{ - $A::b = 1; - A->export_to_level(1, @_); -} + sub import + { + $A::b = 1; + A->export_to_level(1, @_); + } This will export the symbols one level 'above' the current package - ie: to the program or module that used package A.