1: package Exporter;
2:
3: require 5.006;
4:
5:
6:
7:
8:
9: our $Debug = 0;
10: our $ExportLevel = 0;
11: our $Verbose ||= 0;
12: our $VERSION = '5.63';
13: our (%Cache);
14:
15:
16: $Carp::Internal{Exporter}++;
17:
18: sub as_heavy {
19: require Exporter::Heavy;
20:
21:
22: my $c = (caller(1))[3];
23: $c =~ s/.*:://;
24: \&{"Exporter::Heavy::heavy_$c"};
25: }
26:
27: sub export {
28: goto &{as_heavy()};
29: }
30:
31: sub import {
32: my $pkg = shift;
33: my $callpkg = caller($ExportLevel);
34:
35: if ($pkg eq "Exporter" and @_ and $_[0] eq "import") {
36: *{$callpkg."::import"} = \&import;
37: return;
38: }
39:
40:
41: my($exports, $fail) = (\@{"$pkg\::EXPORT"}, \@{"$pkg\::EXPORT_FAIL"});
42: return export $pkg, $callpkg, @_
43: if $Verbose or $Debug or @$fail > 1;
44: my $export_cache = ($Cache{$pkg} ||= {});
45: my $args = @_ or @_ = @$exports;
46:
47: local $_;
48: if ($args and not %$export_cache) {
49: s/^&//, $export_cache->{$_} = 1
50: foreach (@$exports, @{"$pkg\::EXPORT_OK"});
51: }
52: my $heavy;
53:
54:
55: if ($args or $fail) {
56: ($heavy = (/\W/ or $args and not exists $export_cache->{$_}
57: or @$fail and $_ eq $fail->[0])) and last
58: foreach (@_);
59: } else {
60: ($heavy = /\W/) and last
61: foreach (@_);
62: }
63: return export $pkg, $callpkg, ($args ? @_ : ()) if $heavy;
64: local $SIG{__WARN__} =
65: sub {require Carp; &Carp::carp};
66:
67: *{"$callpkg\::$_"} = \&{"$pkg\::$_"} foreach @_;
68: }
69:
70:
71:
72: sub export_fail {
73: my $self = shift;
74: @_;
75: }
76:
77:
78:
79:
80:
81: sub export_to_level {
82: goto &{as_heavy()};
83: }
84:
85: sub export_tags {
86: goto &{as_heavy()};
87: }
88:
89: sub export_ok_tags {
90: goto &{as_heavy()};
91: }
92:
93: sub require_version {
94: goto &{as_heavy()};
95: }
96:
97: 1;
98: __END__
99:
100: =head1 NAME
101:
102: Exporter - Implements default import method for modules
103:
104: =head1 SYNOPSIS
105:
106: In module F<YourModule.pm>:
107:
108: package YourModule;
109: require Exporter;
110: @ISA = qw(Exporter);
111: @EXPORT_OK = qw(munge frobnicate); # symbols to export on request
112:
113: or
114:
115: package YourModule;
116: use Exporter 'import'; # gives you Exporter's import() method directly
117: @EXPORT_OK = qw(munge frobnicate); # symbols to export on request
118:
119: In other files which wish to use C<YourModule>:
120:
121: use YourModule qw(frobnicate); # import listed symbols
122: frobnicate ($left, $right) # calls YourModule::frobnicate
123:
124: Take a look at L</Good Practices> for some variants
125: you will like to use in modern Perl code.
126:
127: =head1 DESCRIPTION
128:
129: The Exporter module implements an C<import> method which allows a module
130: to export functions and variables to its users' namespaces. Many modules
131: use Exporter rather than implementing their own C<import> method because
132: Exporter provides a highly flexible interface, with an implementation optimised
133: for the common case.
134:
135: Perl automatically calls the C<import> method when processing a
136: C<use> statement for a module. Modules and C<use> are documented
137: in L<perlfunc> and L<perlmod>. Understanding the concept of
138: modules and how the C<use> statement operates is important to
139: understanding the Exporter.
140:
141: =head2 How to Export
142:
143: The arrays C<@EXPORT> and C<@EXPORT_OK> in a module hold lists of
144: symbols that are going to be exported into the users name space by
145: default, or which they can request to be exported, respectively. The
146: symbols can represent functions, scalars, arrays, hashes, or typeglobs.
147: The symbols must be given by full name with the exception that the
148: ampersand in front of a function is optional, e.g.
149:
150: @EXPORT = qw(afunc $scalar @array); # afunc is a function
151: @EXPORT_OK = qw(&bfunc %hash *typeglob); # explicit prefix on &bfunc
152:
153: If you are only exporting function names it is recommended to omit the
154: ampersand, as the implementation is faster this way.
155:
156: =head2 Selecting What To Export
157:
158: Do B<not> export method names!
159:
160: Do B<not> export anything else by default without a good reason!
161:
162: Exports pollute the namespace of the module user. If you must export
163: try to use C<@EXPORT_OK> in preference to C<@EXPORT> and avoid short or
164: common symbol names to reduce the risk of name clashes.
165:
166: Generally anything not exported is still accessible from outside the
167: module using the C<YourModule::item_name> (or C<< $blessed_ref->method >>)
168: syntax. By convention you can use a leading underscore on names to
169: informally indicate that they are 'internal' and not for public use.
170:
171: (It is actually possible to get private functions by saying:
172:
173: my $subref = sub { ... };
174: $subref->(@args); # Call it as a function
175: $obj->$subref(@args); # Use it as a method
176:
177: However if you use them for methods it is up to you to figure out
178: how to make inheritance work.)
179:
180: As a general rule, if the module is trying to be object oriented
181: then export nothing. If it's just a collection of functions then
182: C<@EXPORT_OK> anything but use C<@EXPORT> with caution. For function and
183: method names use barewords in preference to names prefixed with
184: ampersands for the export lists.
185:
186: Other module design guidelines can be found in L<perlmod>.
187:
188: =head2 How to Import
189:
190: In other files which wish to use your module there are three basic ways for
191: them to load your module and import its symbols:
192:
193: =over 4
194:
195: =item C<use YourModule;>
196:
197: This imports all the symbols from YourModule's C<@EXPORT> into the namespace
198: of the C<use> statement.
199:
200: =item C<use YourModule ();>
201:
202: This causes perl to load your module but does not import any symbols.
203:
204: =item C<use YourModule qw(...);>
205:
206: This imports only the symbols listed by the caller into their namespace.
207: All listed symbols must be in your C<@EXPORT> or C<@EXPORT_OK>, else an error
208: occurs. The advanced export features of Exporter are accessed like this,
209: but with list entries that are syntactically distinct from symbol names.
210:
211: =back
212:
213: Unless you want to use its advanced features, this is probably all you
214: need to know to use Exporter.
215:
216: =head1 Advanced features
217:
218: =head2 Specialised Import Lists
219:
220: If any of the entries in an import list begins with !, : or / then
221: the list is treated as a series of specifications which either add to
222: or delete from the list of names to import. They are processed left to
223: right. Specifications are in the form:
224:
225: [!]name This name only
226: [!]:DEFAULT All names in @EXPORT
227: [!]:tag All names in $EXPORT_TAGS{tag} anonymous list
228: [!]/pattern/ All names in @EXPORT and @EXPORT_OK which match
229:
230: A leading ! indicates that matching names should be deleted from the
231: list of names to import. If the first specification is a deletion it
232: is treated as though preceded by :DEFAULT. If you just want to import
233: extra names in addition to the default set you will still need to
234: include :DEFAULT explicitly.
235:
236: e.g., F<Module.pm> defines:
237:
238: @EXPORT = qw(A1 A2 A3 A4 A5);
239: @EXPORT_OK = qw(B1 B2 B3 B4 B5);
240: %EXPORT_TAGS = (T1 => [qw(A1 A2 B1 B2)], T2 => [qw(A1 A2 B3 B4)]);
241:
242: Note that you cannot use tags in @EXPORT or @EXPORT_OK.
243: Names in EXPORT_TAGS must also appear in @EXPORT or @EXPORT_OK.
244:
245: An application using Module can say something like:
246:
247: use Module qw(:DEFAULT :T2 !B3 A3);
248:
249: Other examples include:
250:
251: use Socket qw(!/^[AP]F_/ !SOMAXCONN !SOL_SOCKET);
252: use POSIX qw(:errno_h :termios_h !TCSADRAIN !/^EXIT/);
253:
254: Remember that most patterns (using //) will need to be anchored
255: with a leading ^, e.g., C</^EXIT/> rather than C</EXIT/>.
256:
257: You can say C<BEGIN { $Exporter::Verbose=1 }> to see how the
258: specifications are being processed and what is actually being imported
259: into modules.
260:
261: =head2 Exporting without using Exporter's import method
262:
263: Exporter has a special method, 'export_to_level' which is used in situations
264: where you can't directly call Exporter's import method. The export_to_level
265: method looks like:
266:
267: MyPackage->export_to_level($where_to_export, $package, @what_to_export);
268:
269: where C<$where_to_export> is an integer telling how far up the calling stack
270: to export your symbols, and C<@what_to_export> is an array telling what
271: symbols *to* export (usually this is C<@_>). The C<$package> argument is
272: currently unused.
273:
274: For example, suppose that you have a module, A, which already has an
275: import function:
276:
277: package A;
278:
279: @ISA = qw(Exporter);
280: @EXPORT_OK = qw ($b);
281:
282: sub import
283: {
284: $A::b = 1; # not a very useful import method
285: }
286:
287: and you want to Export symbol C<$A::b> back to the module that called
288: package A. Since Exporter relies on the import method to work, via
289: inheritance, as it stands Exporter::import() will never get called.
290: Instead, say the following:
291:
292: package A;
293: @ISA = qw(Exporter);
294: @EXPORT_OK = qw ($b);
295:
296: sub import
297: {
298: $A::b = 1;
299: A->export_to_level(1, @_);
300: }
301:
302: This will export the symbols one level 'above' the current package - ie: to
303: the program or module that used package A.
304:
305: Note: Be careful not to modify C<@_> at all before you call export_to_level
306: - or people using your package will get very unexplained results!
307:
308: =head2 Exporting without inheriting from Exporter
309:
310: By including Exporter in your C<@ISA> you inherit an Exporter's import() method
311: but you also inherit several other helper methods which you probably don't
312: want. To avoid this you can do
313:
314: package YourModule;
315: use Exporter qw( import );
316:
317: which will export Exporter's own import() method into YourModule.
318: Everything will work as before but you won't need to include Exporter in
319: C<@YourModule::ISA>.
320:
321: Note: This feature was introduced in version 5.57
322: of Exporter, released with perl 5.8.3.
323:
324: =head2 Module Version Checking
325:
326: The Exporter module will convert an attempt to import a number from a
327: module into a call to C<< $module_name->require_version($value) >>. This can
328: be used to validate that the version of the module being used is
329: greater than or equal to the required version.
330:
331: The Exporter module supplies a default C<require_version> method which
332: checks the value of C<$VERSION> in the exporting module.
333:
334: Since the default C<require_version> method treats the C<$VERSION> number as
335: a simple numeric value it will regard version 1.10 as lower than
336: 1.9. For this reason it is strongly recommended that you use numbers
337: with at least two decimal places, e.g., 1.09.
338:
339: =head2 Managing Unknown Symbols
340:
341: In some situations you may want to prevent certain symbols from being
342: exported. Typically this applies to extensions which have functions
343: or constants that may not exist on some systems.
344:
345: The names of any symbols that cannot be exported should be listed
346: in the C<@EXPORT_FAIL> array.
347:
348: If a module attempts to import any of these symbols the Exporter
349: will give the module an opportunity to handle the situation before
350: generating an error. The Exporter will call an export_fail method
351: with a list of the failed symbols:
352:
353: @failed_symbols = $module_name->export_fail(@failed_symbols);
354:
355: If the C<export_fail> method returns an empty list then no error is
356: recorded and all the requested symbols are exported. If the returned
357: list is not empty then an error is generated for each symbol and the
358: export fails. The Exporter provides a default C<export_fail> method which
359: simply returns the list unchanged.
360:
361: Uses for the C<export_fail> method include giving better error messages
362: for some symbols and performing lazy architectural checks (put more
363: symbols into C<@EXPORT_FAIL> by default and then take them out if someone
364: actually tries to use them and an expensive check shows that they are
365: usable on that platform).
366:
367: =head2 Tag Handling Utility Functions
368:
369: Since the symbols listed within C<%EXPORT_TAGS> must also appear in either
370: C<@EXPORT> or C<@EXPORT_OK>, two utility functions are provided which allow
371: you to easily add tagged sets of symbols to C<@EXPORT> or C<@EXPORT_OK>:
372:
373: %EXPORT_TAGS = (foo => [qw(aa bb cc)], bar => [qw(aa cc dd)]);
374:
375: Exporter::export_tags('foo'); # add aa, bb and cc to @EXPORT
376: Exporter::export_ok_tags('bar'); # add aa, cc and dd to @EXPORT_OK
377:
378: Any names which are not tags are added to C<@EXPORT> or C<@EXPORT_OK>
379: unchanged but will trigger a warning (with C<-w>) to avoid misspelt tags
380: names being silently added to C<@EXPORT> or C<@EXPORT_OK>. Future versions
381: may make this a fatal error.
382:
383: =head2 Generating combined tags
384:
385: If several symbol categories exist in C<%EXPORT_TAGS>, it's usually
386: useful to create the utility ":all" to simplify "use" statements.
387:
388: The simplest way to do this is:
389:
390: %EXPORT_TAGS = (foo => [qw(aa bb cc)], bar => [qw(aa cc dd)]);
391:
392: # add all the other ":class" tags to the ":all" class,
393: # deleting duplicates
394: {
395: my %seen;
396:
397: push @{$EXPORT_TAGS{all}},
398: grep {!$seen{$_}++} @{$EXPORT_TAGS{$_}} foreach keys %EXPORT_TAGS;
399: }
400:
401: F<CGI.pm> creates an ":all" tag which contains some (but not really
402: all) of its categories. That could be done with one small
403: change:
404:
405: # add some of the other ":class" tags to the ":all" class,
406: # deleting duplicates
407: {
408: my %seen;
409:
410: push @{$EXPORT_TAGS{all}},
411: grep {!$seen{$_}++} @{$EXPORT_TAGS{$_}}
412: foreach qw/html2 html3 netscape form cgi internal/;
413: }
414:
415: Note that the tag names in C<%EXPORT_TAGS> don't have the leading ':'.
416:
417: =head2 C<AUTOLOAD>ed Constants
418:
419: Many modules make use of C<AUTOLOAD>ing for constant subroutines to
420: avoid having to compile and waste memory on rarely used values (see
421: L<perlsub> for details on constant subroutines). Calls to such
422: constant subroutines are not optimized away at compile time because
423: they can't be checked at compile time for constancy.
424:
425: Even if a prototype is available at compile time, the body of the
426: subroutine is not (it hasn't been C<AUTOLOAD>ed yet). perl needs to
427: examine both the C<()> prototype and the body of a subroutine at
428: compile time to detect that it can safely replace calls to that
429: subroutine with the constant value.
430:
431: A workaround for this is to call the constants once in a C<BEGIN> block:
432:
433: package My ;
434:
435: use Socket ;
436:
437: foo( SO_LINGER ); ## SO_LINGER NOT optimized away; called at runtime
438: BEGIN { SO_LINGER }
439: foo( SO_LINGER ); ## SO_LINGER optimized away at compile time.
440:
441: This forces the C<AUTOLOAD> for C<SO_LINGER> to take place before
442: SO_LINGER is encountered later in C<My> package.
443:
444: If you are writing a package that C<AUTOLOAD>s, consider forcing
445: an C<AUTOLOAD> for any constants explicitly imported by other packages
446: or which are usually used when your package is C<use>d.
447:
448: =head1 Good Practices
449:
450: =head2 Declaring C<@EXPORT_OK> and Friends
451:
452: When using C<Exporter> with the standard C<strict> and C<warnings>
453: pragmas, the C<our> keyword is needed to declare the package
454: variables C<@EXPORT_OK>, C<@EXPORT>, C<@ISA>, etc.
455:
456: our @ISA = qw(Exporter);
457: our @EXPORT_OK = qw(munge frobnicate);
458:
459: If backward compatibility for Perls under 5.6 is important,
460: one must write instead a C<use vars> statement.
461:
462: use vars qw(@ISA @EXPORT_OK);
463: @ISA = qw(Exporter);
464: @EXPORT_OK = qw(munge frobnicate);
465:
466: =head2 Playing Safe
467:
468: There are some caveats with the use of runtime statements
469: like C<require Exporter> and the assignment to package
470: variables, which can very subtle for the unaware programmer.
471: This may happen for instance with mutually recursive
472: modules, which are affected by the time the relevant
473: constructions are executed.
474:
475: The ideal (but a bit ugly) way to never have to think
476: about that is to use C<BEGIN> blocks. So the first part
477: of the L</SYNOPSIS> code could be rewritten as:
478:
479: package YourModule;
480:
481: use strict;
482: use warnings;
483:
484: our (@ISA, @EXPORT_OK);
485: BEGIN {
486: require Exporter;
487: @ISA = qw(Exporter);
488: @EXPORT_OK = qw(munge frobnicate); # symbols to export on request
489: }
490:
491: The C<BEGIN> will assure that the loading of F<Exporter.pm>
492: and the assignments to C<@ISA> and C<@EXPORT_OK> happen
493: immediately, leaving no room for something to get awry
494: or just plain wrong.
495:
496: With respect to loading C<Exporter> and inheriting, there
497: are alternatives with the use of modules like C<base> and C<parent>.
498:
499: use base qw( Exporter );
500: # or
501: use parent qw( Exporter );
502:
503: Any of these statements are nice replacements for
504: C<BEGIN { require Exporter; @ISA = qw(Exporter); }>
505: with the same compile-time effect. The basic difference
506: is that C<base> code interacts with declared C<fields>
507: while C<parent> is a streamlined version of the older
508: C<base> code to just establish the IS-A relationship.
509:
510: For more details, see the documentation and code of
511: L<base> and L<parent>.
512:
513: Another thorough remedy to that runtime vs.
514: compile-time trap is to use L<Exporter::Easy>,
515: which is a wrapper of Exporter that allows all
516: boilerplate code at a single gulp in the
517: use statement.
518:
519: use Exporter::Easy (
520: OK => [ qw(munge frobnicate) ],
521: );
522: # @ISA setup is automatic
523: # all assignments happen at compile time
524:
525: =head2 What not to Export
526:
527: You have been warned already in L</Selecting What To Export>
528: to not export:
529:
530: =over 4
531:
532: =item *
533:
534: method names (because you don't need to
535: and that's likely to not do what you want),
536:
537: =item *
538:
539: anything by default (because you don't want to surprise your users...
540: badly)
541:
542: =item *
543:
544: anything you don't need to (because less is more)
545:
546: =back
547:
548: There's one more item to add to this list. Do B<not>
549: export variable names. Just because C<Exporter> lets you
550: do that, it does not mean you should.
551:
552: @EXPORT_OK = qw( $svar @avar %hvar ); # DON'T!
553:
554: Exporting variables is not a good idea. They can
555: change under the hood, provoking horrible
556: effects at-a-distance, that are too hard to track
557: and to fix. Trust me: they are not worth it.
558:
559: To provide the capability to set/get class-wide
560: settings, it is best instead to provide accessors
561: as subroutines or class methods instead.
562:
563: =head1 SEE ALSO
564:
565: C<Exporter> is definitely not the only module with
566: symbol exporter capabilities. At CPAN, you may find
567: a bunch of them. Some are lighter. Some
568: provide improved APIs and features. Peek the one
569: that fits your needs. The following is
570: a sample list of such modules.
571:
572: Exporter::Easy
573: Exporter::Lite
574: Exporter::Renaming
575: Exporter::Tidy
576: Sub::Exporter / Sub::Installer
577: Perl6::Export / Perl6::Export::Attrs
578:
579: =head1 LICENSE
580:
581: This library is free software. You can redistribute it
582: and/or modify it under the same terms as Perl itself.
583:
584: =cut
585:
586:
587: