local-lib5/man/man3/Sub::Exporter.3pm

   1 .\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.3
   2 .\"
   3 .\" Standard preamble:
   4 .\" ========================================================================
   5 .de Sh \" Subsection heading
   6 .br
   7 .if t .Sp
   8 .ne 5
   9 .PP
  10 \fB\\$1\fR
  11 .PP
  12 ..
  13 .de Sp \" Vertical space (when we can't use .PP)
  14 .if t .sp .5v
  15 .if n .sp
  16 ..
  17 .de Vb \" Begin verbatim text
  18 .ft CW
  19 .nf
  20 .ne \\$1
  21 ..
  22 .de Ve \" End verbatim text
  23 .ft R
  24 .fi
  25 ..
  26 .\" Set up some character translations and predefined strings.  \*(-- will
  27 .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
  28 .\" double quote, and \*(R" will give a right double quote.  | will give a
  29 .\" real vertical bar.  \*(C+ will give a nicer C++.  Capital omega is used to
  30 .\" do unbreakable dashes and therefore won't be available.  \*(C` and \*(C'
  31 .\" expand to `' in nroff, nothing in troff, for use with C<>.
  32 .tr \(*W-|\(bv\*(Tr
  33 .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  34 .ie n \{\
  35 .    ds -- \(*W-
  36 .    ds PI pi
  37 .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
  38 .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
  39 .    ds L" ""
  40 .    ds R" ""
  41 .    ds C` ""
  42 .    ds C' ""
  43 'br\}
  44 .el\{\
  45 .    ds -- \|\(em\|
  46 .    ds PI \(*p
  47 .    ds L" ``
  48 .    ds R" ''
  49 'br\}
  50 .\"
  51 .\" If the F register is turned on, we'll generate index entries on stderr for
  52 .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
  53 .\" entries marked with X<> in POD.  Of course, you'll have to process the
  54 .\" output yourself in some meaningful fashion.
  55 .if \nF \{\
  56 .    de IX
  57 .    tm Index:\\$1\t\\n%\t"\\$2"
  58 ..
  59 .    nr % 0
  60 .    rr F
  61 .\}
  62 .\"
  63 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  64 .\" way too many mistakes in technical documents.
  65 .hy 0
  66 .if n .na
  67 .\"
  68 .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
  69 .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
  70 .    \" fudge factors for nroff and troff
  71 .if n \{\
  72 .    ds #H 0
  73 .    ds #V .8m
  74 .    ds #F .3m
  75 .    ds #[ \f1
  76 .    ds #] \fP
  77 .\}
  78 .if t \{\
  79 .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
  80 .    ds #V .6m
  81 .    ds #F 0
  82 .    ds #[ \&
  83 .    ds #] \&
  84 .\}
  85 .    \" simple accents for nroff and troff
  86 .if n \{\
  87 .    ds ' \&
  88 .    ds ` \&
  89 .    ds ^ \&
  90 .    ds , \&
  91 .    ds ~ ~
  92 .    ds /
  93 .\}
  94 .if t \{\
  95 .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
  96 .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
  97 .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
  98 .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
  99 .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
 100 .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
 101 .\}
 102 .    \" troff and (daisy-wheel) nroff accents
 103 .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
 104 .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
 105 .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
 106 .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
 107 .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
 108 .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
 109 .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
 110 .ds ae a\h'-(\w'a'u*4/10)'e
 111 .ds Ae A\h'-(\w'A'u*4/10)'E
 112 .    \" corrections for vroff
 113 .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
 114 .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
 115 .    \" for low resolution devices (crt and lpr)
 116 .if \n(.H>23 .if \n(.V>19 \
 117 \{\
 118 .    ds : e
 119 .    ds 8 ss
 120 .    ds o a
 121 .    ds d- d\h'-1'\(ga
 122 .    ds D- D\h'-1'\(hy
 123 .    ds th \o'bp'
 124 .    ds Th \o'LP'
 125 .    ds ae ae
 126 .    ds Ae AE
 127 .\}
 128 .rm #[ #] #H #V #F C
 129 .\" ========================================================================
 130 .\"
 131 .IX Title "Sub::Exporter 3"
 132 .TH Sub::Exporter 3 "2009-01-16" "perl v5.8.7" "User Contributed Perl Documentation"
 133 .SH "NAME"
 134 Sub::Exporter \- a sophisticated exporter for custom\-built routines
 135 .SH "VERSION"
 136 .IX Header "VERSION"
 137 version 0.982
 138 .SH "SYNOPSIS"
 139 .IX Header "SYNOPSIS"
 140 Sub::Exporter must be used in two places.  First, in an exporting module:
 141 .PP
 142 .Vb 11
 143 \&  # in the exporting module:
 144 \&  package Text::Tweaker;
 145 \&  use Sub::Exporter \-setup => {
 146 \&    exports => [
 147 \&      qw(squish titlecase), # always works the same way
 148 \&      reformat => \e&build_reformatter, # generator to build exported function
 149 \&      trim     => \e&build_trimmer,
 150 \&      indent   => \e&build_indenter,
 151 \&    ],
 152 \&    collectors => [ 'defaults' ],
 153 \&  };
 154 .Ve
 155 .PP
 156 Then, in an importing module:
 157 .PP
 158 .Vb 6
 159 \&  # in the importing module:
 160 \&  use Text::Tweaker
 161 \&    'squish',
 162 \&    indent   => { margin => 5 },
 163 \&    reformat => { width => 79, justify => 'full', \-as => 'prettify_text' },
 164 \&    defaults => { eol => 'CRLF' };
 165 .Ve
 166 .PP
 167 With this setup, the importing module ends up with three routines: \f(CW\*(C`squish\*(C'\fR,
 168 \&\f(CW\*(C`indent\*(C'\fR, and \f(CW\*(C`prettify_text\*(C'\fR.  The latter two have been built to the
 169 specifications of the importer \*(-- they are not just copies of the code in the
 170 exporting package.
 171 .SH "DESCRIPTION"
 172 .IX Header "DESCRIPTION"
 173 \&\fB\s-1ACHTUNG\s0!\fR  If you're not familiar with Exporter or exporting, read
 174 Sub::Exporter::Tutorial first!
 175 .Sh "Why Generators?"
 176 .IX Subsection "Why Generators?"
 177 The biggest benefit of Sub::Exporter over existing exporters (including the
 178 ubiquitous Exporter.pm) is its ability to build new coderefs for export, rather
 179 than to simply export code identical to that found in the exporting package.
 180 .PP
 181 If your module's consumers get a routine that works like this:
 182 .PP
 183 .Vb 2
 184 \&  use Data::Analyze qw(analyze);
 185 \&  my $value = analyze($data, $tolerance, $passes);
 186 .Ve
 187 .PP
 188 and they constantly pass only one or two different set of values for the
 189 non\-\f(CW$data\fR arguments, your code can benefit from Sub::Exporter.  By writing a
 190 simple generator, you can let them do this, instead:
 191 .PP
 192 .Vb 3
 193 \&  use Data::Analyze
 194 \&    analyze => { tolerance => 0.10, passes => 10, \-as => analyze10 },
 195 \&    analyze => { tolerance => 0.15, passes => 50, \-as => analyze50 };
 196 .Ve
 197 .PP
 198 .Vb 1
 199 \&  my $value = analyze10($data);
 200 .Ve
 201 .PP
 202 The generator for that would look something like this:
 203 .PP
 204 .Vb 2
 205 \&  sub build_analyzer {
 206 \&    my ($class, $name, $arg) = @_;
 207 .Ve
 208 .PP
 209 .Vb 4
 210 \&    return sub {
 211 \&      my $data      = shift;
 212 \&      my $tolerance = shift || $arg\->{tolerance};
 213 \&      my $passes    = shift || $arg\->{passes};
 214 .Ve
 215 .PP
 216 .Vb 3
 217 \&      analyze($data, $tolerance, $passes);
 218 \&    }
 219 \&  }
 220 .Ve
 221 .PP
 222 Your module's user now has to do less work to benefit from it \*(-- and remember,
 223 you're often your own user!  Investing in customized subroutines is an
 224 investment in future laziness.
 225 .PP
 226 This also avoids a common form of ugliness seen in many modules: package-level
 227 configuration.  That is, you might have seen something like the above
 228 implemented like so:
 229 .PP
 230 .Vb 3
 231 \&  use Data::Analyze qw(analyze);
 232 \&  $Data::Analyze::default_tolerance = 0.10;
 233 \&  $Data::Analyze::default_passes    = 10;
 234 .Ve
 235 .PP
 236 This might save time, until you have multiple modules using Data::Analyze.
 237 Because there is only one global configuration, they step on each other's toes
 238 and your code begins to have mysterious errors.
 239 .PP
 240 Generators can also allow you to export class methods to be called as
 241 subroutines:
 242 .PP
 243 .Vb 2
 244 \&  package Data::Methodical;
 245 \&  use Sub::Exporter \-setup => { exports => { some_method => \e&_curry_class } };
 246 .Ve
 247 .PP
 248 .Vb 4
 249 \&  sub _curry_class {
 250 \&    my ($class, $name) = @_;
 251 \&    sub { $class\->$name(@_); };
 252 \&  }
 253 .Ve
 254 .PP
 255 Because of the way that exporters and Sub::Exporter work, any package that
 256 inherits from Data::Methodical can inherit its exporter and override its
 257 \&\f(CW\*(C`some_method\*(C'\fR.  If a user imports \f(CW\*(C`some_method\*(C'\fR from that package, he'll
 258 receive a subroutine that calls the method on the subclass, rather than on
 259 Data::Methodical itself.
 260 .Sh "Other Customizations"
 261 .IX Subsection "Other Customizations"
 262 Building custom routines with generators isn't the only way that Sub::Exporters
 263 allows the importing code to refine its use of the exported routines.  They may
 264 also be renamed to avoid naming collisions.
 265 .PP
 266 Consider the following code:
 267 .PP
 268 .Vb 3
 269 \&  # this program determines to which circle of Hell you will be condemned
 270 \&  use Morality qw(sin virtue); # for calculating viciousness
 271 \&  use Math::Trig qw(:all);     # for dealing with circles
 272 .Ve
 273 .PP
 274 The programmer has inadvertantly imported two \f(CW\*(C`sin\*(C'\fR routines.  The solution,
 275 in Exporter.pm\-based modules, would be to import only one and then call the
 276 other by its fully-qualified name.  Alternately, the importer could write a
 277 routine that did so, or could mess about with typeglobs.
 278 .PP
 279 How much easier to write:
 280 .PP
 281 .Vb 3
 282 \&  # this program determines to which circle of Hell you will be condemned
 283 \&  use Morality qw(virtue), sin => { \-as => 'offense' };
 284 \&  use Math::Trig \-all => { \-prefix => 'trig_' };
 285 .Ve
 286 .PP
 287 and to have at one's disposal \f(CW\*(C`offense\*(C'\fR and \f(CW\*(C`trig_sin\*(C'\fR \*(-- not to mention
 288 \&\f(CW\*(C`trig_cos\*(C'\fR and \f(CW\*(C`trig_tan\*(C'\fR.
 289 .SH "EXPORTER CONFIGURATION"
 290 .IX Header "EXPORTER CONFIGURATION"
 291 You can configure an exporter for your package by using Sub::Exporter like so:
 292 .PP
 293 .Vb 3
 294 \&  package Tools;
 295 \&  use Sub::Exporter
 296 \&    \-setup => { exports => [ qw(function1 function2 function3) ] };
 297 .Ve
 298 .PP
 299 This is the simplest way to use the exporter, and is basically equivalent to
 300 this:
 301 .PP
 302 .Vb 3
 303 \&  package Tools;
 304 \&  use base qw(Exporter);
 305 \&  our @EXPORT_OK = qw(function1 function2 function2);
 306 .Ve
 307 .PP
 308 Any basic use of Sub::Exporter will look like this:
 309 .PP
 310 .Vb 2
 311 \&  package Tools;
 312 \&  use Sub::Exporter \-setup => \e%config;
 313 .Ve
 314 .PP
 315 The following keys are valid in \f(CW%config\fR:
 316 .PP
 317 .Vb 5
 318 \&  exports \- a list of routines to provide for exporting; each routine may be
 319 \&            followed by generator
 320 \&  groups  \- a list of groups to provide for exporting; each must be followed by
 321 \&            either (a) a list of exports, possibly with arguments for each
 322 \&            export, or (b) a generator
 323 .Ve
 324 .PP
 325 .Vb 2
 326 \&  collectors \- a list of names into which values are collected for use in
 327 \&               routine generation; each name may be followed by a validator
 328 .Ve
 329 .PP
 330 In addition to the basic options above, a few more advanced options may be
 331 passed:
 332 .PP
 333 .Vb 2
 334 \&  into_level \- how far up the caller stack to look for a target (default 0)
 335 \&  into       \- an explicit target (package) into which to export routines
 336 .Ve
 337 .PP
 338 In other words: Sub::Exporter installs a \f(CW\*(C`import\*(C'\fR routine which, when called,
 339 exports routines to the calling namespace.  The \f(CW\*(C`into\*(C'\fR and \f(CW\*(C`into_level\*(C'\fR
 340 options change where those exported routines are installed.
 341 .PP
 342 .Vb 2
 343 \&  generator  \- a callback used to produce the code that will be installed
 344 \&               default: Sub::Exporter::default_generator
 345 .Ve
 346 .PP
 347 .Vb 2
 348 \&  installer  \- a callback used to install the code produced by the generator
 349 \&               default: Sub::Exporter::default_installer
 350 .Ve
 351 .PP
 352 For information on how these callbacks are used, see the documentation for
 353 \&\f(CW\*(C`\*(L"default_generator\*(R"\*(C'\fR and \f(CW\*(C`\*(L"default_installer\*(R"\*(C'\fR.
 354 .Sh "Export Configuration"
 355 .IX Subsection "Export Configuration"
 356 The \f(CW\*(C`exports\*(C'\fR list may be provided as an array reference or a hash reference.
 357 The list is processed in such a way that the following are equivalent:
 358 .PP
 359 .Vb 1
 360 \&  { exports => [ qw(foo bar baz), quux => \e&quux_generator ] }
 361 .Ve
 362 .PP
 363 .Vb 2
 364 \&  { exports =>
 365 \&    { foo => undef, bar => undef, baz => undef, quux => \e&quux_generator } }
 366 .Ve
 367 .PP
 368 Generators are code that return coderefs.  They are called with four
 369 parameters:
 370 .PP
 371 .Vb 4
 372 \&  $class \- the class whose exporter has been called (the exporting class)
 373 \&  $name  \- the name of the export for which the routine is being build
 374 \& \e%arg   \- the arguments passed for this export
 375 \& \e%col   \- the collections for this import
 376 .Ve
 377 .PP
 378 Given the configuration in the \*(L"\s-1SYNOPSIS\s0\*(R", the following \f(CW\*(C`use\*(C'\fR statement:
 379 .PP
 380 .Vb 3
 381 \&  use Text::Tweaker
 382 \&    reformat => { \-as => 'make_narrow', width => 33 },
 383 \&    defaults => { eol => 'CR' };
 384 .Ve
 385 .PP
 386 would result in the following call to \f(CW&build_reformatter\fR:
 387 .PP
 388 .Vb 6
 389 \&  my $code = build_reformatter(
 390 \&    'Text::Tweaker',
 391 \&    'reformat',
 392 \&    { width => 33 }, # note that \-as is not passed in
 393 \&    { defaults => { eol => 'CR' } },
 394 \&  );
 395 .Ve
 396 .PP
 397 The returned coderef (\f(CW$code\fR) would then be installed as \f(CW\*(C`make_narrow\*(C'\fR in the
 398 calling package.
 399 .PP
 400 Instead of providing a coderef in the configuration, a reference to a method
 401 name may be provided.  This method will then be called on the invocant of the
 402 \&\f(CW\*(C`import\*(C'\fR method.  (In this case, we do not pass the \f(CW$class\fR parameter, as it
 403 would be redundant.)
 404 .Sh "Group Configuration"
 405 .IX Subsection "Group Configuration"
 406 The \f(CW\*(C`groups\*(C'\fR list can be passed in the same forms as \f(CW\*(C`exports\*(C'\fR.  Groups must
 407 have values to be meaningful, which may either list exports that make up the
 408 group (optionally with arguments) or may provide a way to build the group.
 409 .PP
 410 The simpler case is the first: a group definition is a list of exports.  Here's
 411 the example that could go in exporter in the \*(L"\s-1SYNOPSIS\s0\*(R".
 412 .PP
 413 .Vb 8
 414 \&  groups  => {
 415 \&    default    => [ qw(reformat) ],
 416 \&    shorteners => [ qw(squish trim) ],
 417 \&    email_safe => [
 418 \&      'indent',
 419 \&      reformat => { \-as => 'email_format', width => 72 }
 420 \&    ],
 421 \&  },
 422 .Ve
 423 .PP
 424 Groups are imported by specifying their name prefixed be either a dash or a
 425 colon.  This line of code would import the \f(CW\*(C`shorteners\*(C'\fR group:
 426 .PP
 427 .Vb 1
 428 \&  use Text::Tweaker qw(\-shorteners);
 429 .Ve
 430 .PP
 431 Arguments passed to a group when importing are merged into the groups options
 432 and passed to any relevant generators.  Groups can contain other groups, but
 433 looping group structures are ignored.
 434 .PP
 435 The other possible value for a group definition, a coderef, allows one
 436 generator to build several exportable routines simultaneously.  This is useful
 437 when many routines must share enclosed lexical variables.  The coderef must
 438 return a hash reference.  The keys will be used as export names and the values
 439 are the subs that will be exported.
 440 .PP
 441 This example shows a simple use of the group generator.
 442 .PP
 443 .Vb 2
 444 \&  package Data::Crypto;
 445 \&  use Sub::Exporter \-setup => { groups => { cipher => \e&build_cipher_group } };
 446 .Ve
 447 .PP
 448 .Vb 5
 449 \&  sub build_cipher_group {
 450 \&    my ($class, $group, $arg) = @_;
 451 \&    my ($encode, $decode) = build_codec($arg\->{secret});
 452 \&    return { cipher => $encode, decipher => $decode };
 453 \&  }
 454 .Ve
 455 .PP
 456 The \f(CW\*(C`cipher\*(C'\fR and \f(CW\*(C`decipher\*(C'\fR routines are built in a group because they are
 457 built together by code which encloses their secret in their environment.
 458 .PP
 459 \fIDefault Groups\fR
 460 .IX Subsection "Default Groups"
 461 .PP
 462 If a module that uses Sub::Exporter is \f(CW\*(C`use\*(C'\fRd with no arguments, it will try
 463 to export the group named \f(CW\*(C`default\*(C'\fR.  If that group has not been specifically
 464 configured, it will be empty, and nothing will happen.
 465 .PP
 466 Another group is also created if not defined: \f(CW\*(C`all\*(C'\fR.  The \f(CW\*(C`all\*(C'\fR group
 467 contains all the exports from the exports list.
 468 .Sh "Collector Configuration"
 469 .IX Subsection "Collector Configuration"
 470 The \f(CW\*(C`collectors\*(C'\fR entry in the exporter configuration gives names which, when
 471 found in the import call, have their values collected and passed to every
 472 generator.
 473 .PP
 474 For example, the \f(CW\*(C`build_analyzer\*(C'\fR generator that we saw above could be
 475 rewritten as:
 476 .PP
 477 .Vb 2
 478 \& sub build_analyzer {
 479 \&   my ($class, $name, $arg, $col) = @_;
 480 .Ve
 481 .PP
 482 .Vb 4
 483 \&   return sub {
 484 \&     my $data      = shift;
 485 \&     my $tolerance = shift || $arg\->{tolerance} || $col\->{defaults}{tolerance};
 486 \&     my $passes    = shift || $arg\->{passes}    || $col\->{defaults}{passes};
 487 .Ve
 488 .PP
 489 .Vb 3
 490 \&     analyze($data, $tolerance, $passes);
 491 \&   }
 492 \& }
 493 .Ve
 494 .PP
 495 That would allow the import to specify global defaults for his imports:
 496 .PP
 497 .Vb 5
 498 \&  use Data::Analyze
 499 \&    'analyze',
 500 \&    analyze  => { tolerance => 0.10, \-as => analyze10 },
 501 \&    analyze  => { tolerance => 0.15, passes => 50, \-as => analyze50 },
 502 \&    defaults => { passes => 10 };
 503 .Ve
 504 .PP
 505 .Vb 3
 506 \&  my $A = analyze10($data);     # equivalent to analyze($data, 0.10, 10);
 507 \&  my $C = analyze50($data);     # equivalent to analyze($data, 0.15, 10);
 508 \&  my $B = analyze($data, 0.20); # equivalent to analyze($data, 0.20, 10);
 509 .Ve
 510 .PP
 511 If values are provided in the \f(CW\*(C`collectors\*(C'\fR list during exporter setup, they
 512 must be code references, and are used to validate the importer's values.  The
 513 validator is called when the collection is found, and if it returns false, an
 514 exception is thrown.  We could ensure that no one tries to set a global data
 515 default easily:
 516 .PP
 517 .Vb 1
 518 \&  collectors => { defaults => sub { return (exists $_[0]\->{data}) ? 0 : 1 } }
 519 .Ve
 520 .PP
 521 Collector coderefs can also be used as hooks to perform arbitrary actions
 522 before anything is exported.
 523 .PP
 524 When the coderef is called, it is passed the value of the collection and a
 525 hashref containing the following entries:
 526 .PP
 527 .Vb 5
 528 \&  name        \- the name of the collector
 529 \&  config      \- the exporter configuration (hashref)
 530 \&  import_args \- the arguments passed to the exporter, sans collections (aref)
 531 \&  class       \- the package on which the importer was called
 532 \&  into        \- the package into which exports will be exported
 533 .Ve
 534 .PP
 535 Collectors with all-caps names (that is, made up of underscore or capital A
 536 through Z) are reserved for special use.  The only currently implemented
 537 special collector is \f(CW\*(C`INIT\*(C'\fR, whose hook (if present in the exporter
 538 configuration) is always run before any other hook.
 539 .SH "CALLING THE EXPORTER"
 540 .IX Header "CALLING THE EXPORTER"
 541 Arguments to the exporter (that is, the arguments after the module name in a
 542 \&\f(CW\*(C`use\*(C'\fR statement) are parsed as follows:
 543 .PP
 544 First, the collectors gather any collections found in the arguments.  Any
 545 reference type may be given as the value for a collector.  For each collection
 546 given in the arguments, its validator (if any) is called.
 547 .PP
 548 Next, groups are expanded.  If the group is implemented by a group generator,
 549 the generator is called.  There are two special arguments which, if given to a
 550 group, have special meaning:
 551 .PP
 552 .Vb 2
 553 \&  \-prefix \- a string to prepend to any export imported from this group
 554 \&  \-suffix \- a string to append to any export imported from this group
 555 .Ve
 556 .PP
 557 Finally, individual export generators are called and all subs, generated or
 558 otherwise, are installed in the calling package.  There is only one special
 559 argument for export generators:
 560 .PP
 561 .Vb 1
 562 \&  \-as     \- where to install the exported sub
 563 .Ve
 564 .PP
 565 Normally, \f(CW\*(C`\-as\*(C'\fR will contain an alternate name for the routine.  It may,
 566 however, contain a reference to a scalar.  If that is the case, a reference the
 567 generated routine will be placed in the scalar referenced by \f(CW\*(C`\-as\*(C'\fR.  It will
 568 not be installed into the calling package.
 569 .Sh "Special Exporter Arguments"
 570 .IX Subsection "Special Exporter Arguments"
 571 The generated exporter accept some special options, which may be passed as the
 572 first argument, in a hashref.
 573 .PP
 574 These options are:
 575 .PP
 576 .Vb 4
 577 \&  into_level
 578 \&  into
 579 \&  generator
 580 \&  installer
 581 .Ve
 582 .PP
 583 These override the same-named configuration options described in \*(L"\s-1EXPORTER\s0 \s-1CONFIGURATION\s0\*(R".
 584 .SH "SUBROUTINES"
 585 .IX Header "SUBROUTINES"
 586 .Sh "setup_exporter"
 587 .IX Subsection "setup_exporter"
 588 This routine builds and installs an \f(CW\*(C`import\*(C'\fR routine.  It is called with one
 589 argument, a hashref containing the exporter configuration.  Using this, it
 590 builds an exporter and installs it into the calling package with the name
 591 \&\*(L"import.\*(R"  In addition to the normal exporter configuration, a few named
 592 arguments may be passed in the hashref:
 593 .PP
 594 .Vb 3
 595 \&  into       \- into what package should the exporter be installed
 596 \&  into_level \- into what level up the stack should the exporter be installed
 597 \&  as         \- what name should the installed exporter be given
 598 .Ve
 599 .PP
 600 By default the exporter is installed with the name \f(CW\*(C`import\*(C'\fR into the immediate
 601 caller of \f(CW\*(C`setup_exporter\*(C'\fR.  In other words, if your package calls
 602 \&\f(CW\*(C`setup_exporter\*(C'\fR without providing any of the three above arguments, it will
 603 have an \f(CW\*(C`import\*(C'\fR routine installed.
 604 .PP
 605 Providing both \f(CW\*(C`into\*(C'\fR and \f(CW\*(C`into_level\*(C'\fR will cause an exception to be thrown.
 606 .PP
 607 The exporter is built by \f(CW\*(C`\*(L"build_exporter\*(R"\*(C'\fR.
 608 .Sh "build_exporter"
 609 .IX Subsection "build_exporter"
 610 Given a standard exporter configuration, this routine builds and returns an
 611 exporter \*(-- that is, a subroutine that can be installed as a class method to
 612 perform exporting on request.
 613 .PP
 614 Usually, this method is called by \f(CW\*(C`\*(L"setup_exporter\*(R"\*(C'\fR, which then installs
 615 the exporter as a package's import routine.
 616 .Sh "default_generator"
 617 .IX Subsection "default_generator"
 618 This is Sub::Exporter's default generator.  It takes bits of configuration that
 619 have been gathered during the import and turns them into a coderef that can be
 620 installed.
 621 .PP
 622 .Vb 1
 623 \&  my $code = default_generator(\e%arg);
 624 .Ve
 625 .PP
 626 Passed arguments are:
 627 .PP
 628 .Vb 4
 629 \&  class \- the class on which the import method was called
 630 \&  name  \- the name of the export being generated
 631 \&  arg   \- the arguments to the generator
 632 \&  col   \- the collections
 633 .Ve
 634 .PP
 635 .Vb 1
 636 \&  generator \- the generator to be used to build the export (code or scalar ref)
 637 .Ve
 638 .Sh "default_installer"
 639 .IX Subsection "default_installer"
 640 This is Sub::Exporter's default installer.  It does what Sub::Exporter
 641 promises: it installs code into the target package.
 642 .PP
 643 .Vb 1
 644 \&  default_installer(\e%arg, \e@to_export);
 645 .Ve
 646 .PP
 647 Passed arguments are:
 648 .PP
 649 .Vb 1
 650 \&  into \- the package into which exports should be delivered
 651 .Ve
 652 .PP
 653 \&\f(CW@to_export\fR is a list of name/value pairs.  The default exporter assigns code
 654 (the values) to named slots (the names) in the given package.  If the name is a
 655 scalar reference, the scalar reference is made to point to the code reference
 656 instead.
 657 .SH "EXPORTS"
 658 .IX Header "EXPORTS"
 659 Sub::Exporter also offers its own exports: the \f(CW\*(C`setup_exporter\*(C'\fR and
 660 \&\f(CW\*(C`build_exporter\*(C'\fR routines described above.  It also provides a special \*(L"setup\*(R"
 661 collector, which will set up an exporter using the parameters passed to it.
 662 .PP
 663 Note that the \*(L"setup\*(R" collector (seen in examples like the \*(L"\s-1SYNOPSIS\s0\*(R" above)
 664 uses \f(CW\*(C`build_exporter\*(C'\fR, not \f(CW\*(C`setup_exporter\*(C'\fR.  This means that the special
 665 arguments like \*(L"into\*(R" and \*(L"as\*(R" for \f(CW\*(C`setup_exporter\*(C'\fR are not accepted here.
 666 Instead, you may write something like:
 667 .PP
 668 .Vb 7
 669 \&  use Sub::Exporter
 670 \&    { into => 'Target::Package' },
 671 \&    \-setup => {
 672 \&      \-as     => 'do_import',
 673 \&      exports => [ ... ],
 674 \&    }
 675 \&  ;
 676 .Ve
 677 .PP
 678 Finding a good reason for wanting to do this is left as as exercise for the
 679 reader.
 680 .SH "COMPARISONS"
 681 .IX Header "COMPARISONS"
 682 There are a whole mess of exporters on the \s-1CPAN\s0.  The features included in
 683 Sub::Exporter set it apart from any existing Exporter.  Here's a summary of
 684 some other exporters and how they compare.
 685 .IP "* Exporter and co." 4
 686 .IX Item "Exporter and co."
 687 This is the standard Perl exporter.  Its interface is a little clunky, but it's
 688 fast and ubiquitous.  It can do some things that Sub::Exporter can't:  it can
 689 export things other than routines, it can import \*(L"everything in this group
 690 except this symbol,\*(R" and some other more esoteric things.  These features seem
 691 to go nearly entirely unused.
 692 .Sp
 693 It always exports things exactly as they appear in the exporting module; it
 694 can't rename or customize routines.  Its groups (\*(L"tags\*(R") can't be nested.
 695 .Sp
 696 Exporter::Lite is a whole lot like Exporter, but it does significantly less:
 697 it supports exporting symbols, but not groups, pattern matching, or negation.
 698 .Sp
 699 The fact that Sub::Exporter can't export symbols other than subroutines is
 700 a good idea, not a missing feature.
 701 .Sp
 702 For simple uses, setting up Sub::Exporter is about as easy as Exporter.  For
 703 complex uses, Sub::Exporter makes hard things possible, which would not be
 704 possible with Exporter.
 705 .Sp
 706 When using a module that uses Sub::Exporter, users familiar with Exporter will
 707 probably see no difference in the basics.  These two lines do about the same
 708 thing in whether the exporting module uses Exporter or Sub::Exporter.
 709 .Sp
 710 .Vb 2
 711 \&  use Some::Module qw(foo bar baz);
 712 \&  use Some::Module qw(foo :bar baz);
 713 .Ve
 714 .Sp
 715 The definition for exporting in Exporter.pm might look like this:
 716 .Sp
 717 .Vb 4
 718 \&  package Some::Module;
 719 \&  use base qw(Exporter);
 720 \&  our @EXPORT_OK   = qw(foo bar baz quux);
 721 \&  our %EXPORT_TAGS = (bar => [ qw(bar baz) ]);
 722 .Ve
 723 .Sp
 724 Using Sub::Exporter, it would look like this:
 725 .Sp
 726 .Vb 5
 727 \&  package Some::Module;
 728 \&  use Sub::Exporter \-setup => {
 729 \&    exports => [ qw(foo bar baz quux) ],
 730 \&    groups  => { bar => [ qw(bar baz) ]}
 731 \&  };
 732 .Ve
 733 .Sp
 734 Sub::Exporter respects inheritance, so that a package may export inherited
 735 routines, and will export the most inherited version.  Exporting methods
 736 without currying away the invocant is a bad idea, but Sub::Exporter allows you
 737 to do just that \*(-- and anyway, there are other uses for this feature, like
 738 packages of exported subroutines which use inheritance specifically to allow
 739 more specialized, but similar, packages.
 740 .Sp
 741 Exporter::Easy provides a wrapper around the standard Exporter.  It makes it
 742 simpler to build groups, but doesn't provide any more functionality.  Because
 743 it is a front-end to Exporter, it will store your exporter's configuration in
 744 global package variables.
 745 .IP "* Attribute-Based Exporters" 4
 746 .IX Item "Attribute-Based Exporters"
 747 Some exporters use attributes to mark variables to export.  Exporter::Simple
 748 supports exporting any kind of symbol, and supports groups.  Using a module
 749 like Exporter or Sub::Exporter, it's easy to look at one place and see what is
 750 exported, but it's impossible to look at a variable definition and see whether
 751 it is exported by that alone.  Exporter::Simple makes this trade in reverse:
 752 each variable's declaration includes its export definition, but there is no one
 753 place to look to find a manifest of exports.
 754 .Sp
 755 More importantly, Exporter::Simple does not add any new features to those of
 756 Exporter.  In fact, like Exporter::Easy, it is just a front-end to Exporter, so
 757 it ends up storing its configuration in global package variables.  (This means
 758 that there is one place to look for your exporter's manifest, actually.  You
 759 can inspect the \f(CW@EXPORT\fR package variables, and other related package
 760 variables, at runtime.)
 761 .Sp
 762 Perl6::Export isn't actually attribute based, but looks similar.  Its syntax
 763 is borrowed from Perl 6, and implemented by a source filter.  It is a prototype
 764 of an interface that is still being designed.  It should probably be avoided
 765 for production work.  On the other hand, Perl6::Export::Attrs implements
 766 Perl 6\-like exporting, but translates it into Perl 5 by providing attributes.
 767 .IP "* Other Exporters" 4
 768 .IX Item "Other Exporters"
 769 Exporter::Renaming wraps the standard Exporter to allow it to export symbols
 770 with changed names.
 771 .Sp
 772 Class::Exporter performs a special kind of routine generation, giving each
 773 importing package an instance of your class, and then exporting the instance's
 774 methods as normal routines.  (Sub::Exporter, of course, can easily emulate this
 775 behavior, as shown above.)
 776 .Sp
 777 Exporter::Tidy implements a form of renaming (using its \f(CW\*(C`_map\*(C'\fR argument)
 778 and of prefixing, and implements groups.  It also avoids using package
 779 variables for its configuration.
 780 .SH "TODO"
 781 .IX Header "TODO"
 782 .IP "* write a set of longer, more demonstrative examples" 4
 783 .IX Item "write a set of longer, more demonstrative examples"
 784 .PD 0
 785 .ie n .IP "* solidify the ""custom exporter"" interface (see &default_exporter)" 4
 786 .el .IP "* solidify the ``custom exporter'' interface (see \f(CW&default_exporter\fR)" 4
 787 .IX Item "solidify the custom exporter interface (see &default_exporter)"
 788 .ie n .IP "* add an ""always"" group" 4
 789 .el .IP "* add an ``always'' group" 4
 790 .IX Item "add an always group"
 791 .PD
 792 .SH "AUTHOR"
 793 .IX Header "AUTHOR"
 794 Ricardo \s-1SIGNES\s0, \f(CW\*(C`<rjbs@cpan.org>\*(C'\fR
 795 .SH "THANKS"
 796 .IX Header "THANKS"
 797 Hans Dieter Pearcey provided helpful advice while I was writing Sub::Exporter.
 798 Ian Langworth and Shawn Sorichetti asked some good questions and hepled me
 799 improve my documentation quite a bit.  Yuval Kogman helped me find a bunch of
 800 little problems.
 801 .PP
 802 Thanks, guys!
 803 .SH "BUGS"
 804 .IX Header "BUGS"
 805 Please report any bugs or feature requests through the web interface at
 806 <http://rt.cpan.org>. I will be notified, and then you'll automatically be
 807 notified of progress on your bug as I make changes.
 808 .SH "COPYRIGHT"
 809 .IX Header "COPYRIGHT"
 810 Copyright 2006\-2007, Ricardo \s-1SIGNES\s0.  This program is free software;  you can
 811 redistribute it and/or modify it under the same terms as Perl itself.