{ "content": [ { "type": "text", "text": "# Sub::Exporter (perldoc)\n\n## NAME\n\nSub::Exporter - a sophisticated exporter for custom-built routines\n\n## SYNOPSIS\n\nSub::Exporter must be used in two places. First, in an exporting module:\n# in the exporting module:\npackage Text::Tweaker;\nuse Sub::Exporter -setup => {\nexports => [\nqw(squish titlecase), # always works the same way\nreformat => \\&buildreformatter, # generator to build exported function\ntrim => \\&buildtrimmer,\nindent => \\&buildindenter,\n],\ncollectors => [ 'defaults' ],\n};\nThen, in an importing module:\n# in the importing module:\nuse Text::Tweaker\n'squish',\nindent => { margin => 5 },\nreformat => { width => 79, justify => 'full', -as => 'prettifytext' },\ndefaults => { eol => 'CRLF' };\nWith this setup, the importing module ends up with three routines: \"squish\", \"indent\", and\n\"prettifytext\". The latter two have been built to the specifications of the importer -- they\nare not just copies of the code in the exporting package.\n\n## DESCRIPTION\n\nACHTUNG! If you're not familiar with Exporter or exporting, read Sub::Exporter::Tutorial first!\n\n## Sections\n\n- **NAME**\n- **VERSION**\n- **SYNOPSIS**\n- **DESCRIPTION** (1 subsections)\n- **PERL VERSION SUPPORT**\n- **EXPORTER CONFIGURATION** (3 subsections)\n- **CALLING THE EXPORTER** (1 subsections)\n- **SUBROUTINES**\n- **EXPORTS**\n- **COMPARISONS**\n- **TODO**\n- **THANKS**\n- **BUGS**\n- **AUTHOR**\n- **CONTRIBUTORS**\n- **COPYRIGHT AND LICENSE**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "Sub::Exporter", "section": "", "mode": "perldoc", "summary": "Sub::Exporter - a sophisticated exporter for custom-built routines", "synopsis": "Sub::Exporter must be used in two places. First, in an exporting module:\n# in the exporting module:\npackage Text::Tweaker;\nuse Sub::Exporter -setup => {\nexports => [\nqw(squish titlecase), # always works the same way\nreformat => \\&buildreformatter, # generator to build exported function\ntrim => \\&buildtrimmer,\nindent => \\&buildindenter,\n],\ncollectors => [ 'defaults' ],\n};\nThen, in an importing module:\n# in the importing module:\nuse Text::Tweaker\n'squish',\nindent => { margin => 5 },\nreformat => { width => 79, justify => 'full', -as => 'prettifytext' },\ndefaults => { eol => 'CRLF' };\nWith this setup, the importing module ends up with three routines: \"squish\", \"indent\", and\n\"prettifytext\". The latter two have been built to the specifications of the importer -- they\nare not just copies of the code in the exporting package.", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "VERSION", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 27, "subsections": [] }, { "name": "DESCRIPTION", "lines": 75, "subsections": [ { "name": "Other Customizations", "lines": 23 } ] }, { "name": "PERL VERSION SUPPORT", "lines": 7, "subsections": [] }, { "name": "EXPORTER CONFIGURATION", "lines": 46, "subsections": [ { "name": "Export Configuration", "lines": 36 }, { "name": "Group Configuration", "lines": 51 }, { "name": "Collector Configuration", "lines": 52 } ] }, { "name": "CALLING THE EXPORTER", "lines": 22, "subsections": [ { "name": "Special Exporter Arguments", "lines": 12 } ] }, { "name": "SUBROUTINES", "lines": 54, "subsections": [] }, { "name": "EXPORTS", "lines": 18, "subsections": [] }, { "name": "COMPARISONS", "lines": 87, "subsections": [] }, { "name": "TODO", "lines": 6, "subsections": [] }, { "name": "THANKS", "lines": 6, "subsections": [] }, { "name": "BUGS", "lines": 4, "subsections": [] }, { "name": "AUTHOR", "lines": 2, "subsections": [] }, { "name": "CONTRIBUTORS", "lines": 10, "subsections": [] }, { "name": "COPYRIGHT AND LICENSE", "lines": 5, "subsections": [] } ], "sections": { "NAME": { "content": "Sub::Exporter - a sophisticated exporter for custom-built routines\n", "subsections": [] }, "VERSION": { "content": "version 0.988\n", "subsections": [] }, "SYNOPSIS": { "content": "Sub::Exporter must be used in two places. First, in an exporting module:\n\n# in the exporting module:\npackage Text::Tweaker;\nuse Sub::Exporter -setup => {\nexports => [\nqw(squish titlecase), # always works the same way\nreformat => \\&buildreformatter, # generator to build exported function\ntrim => \\&buildtrimmer,\nindent => \\&buildindenter,\n],\ncollectors => [ 'defaults' ],\n};\n\nThen, in an importing module:\n\n# in the importing module:\nuse Text::Tweaker\n'squish',\nindent => { margin => 5 },\nreformat => { width => 79, justify => 'full', -as => 'prettifytext' },\ndefaults => { eol => 'CRLF' };\n\nWith this setup, the importing module ends up with three routines: \"squish\", \"indent\", and\n\"prettifytext\". The latter two have been built to the specifications of the importer -- they\nare not just copies of the code in the exporting package.\n", "subsections": [] }, "DESCRIPTION": { "content": "ACHTUNG! If you're not familiar with Exporter or exporting, read Sub::Exporter::Tutorial first!\n\nWhy Generators?\nThe biggest benefit of Sub::Exporter over existing exporters (including the ubiquitous\nExporter.pm) is its ability to build new coderefs for export, rather than to simply export code\nidentical to that found in the exporting package.\n\nIf your module's consumers get a routine that works like this:\n\nuse Data::Analyze qw(analyze);\nmy $value = analyze($data, $tolerance, $passes);\n\nand they constantly pass only one or two different set of values for the non-$data arguments,\nyour code can benefit from Sub::Exporter. By writing a simple generator, you can let them do\nthis, instead:\n\nuse Data::Analyze\nanalyze => { tolerance => 0.10, passes => 10, -as => analyze10 },\nanalyze => { tolerance => 0.15, passes => 50, -as => analyze50 };\n\nmy $value = analyze10($data);\n\nThe package with the generator for that would look something like this:\n\npackage Data::Analyze;\nuse Sub::Exporter -setup => {\nexports => [\nanalyze => \\&buildanalyzer,\n],\n};\n\nsub buildanalyzer {\nmy ($class, $name, $arg) = @;\n\nreturn sub {\nmy $data = shift;\nmy $tolerance = shift || $arg->{tolerance};\nmy $passes = shift || $arg->{passes};\n\nanalyze($data, $tolerance, $passes);\n}\n}\n\nYour module's user now has to do less work to benefit from it -- and remember, you're often your\nown user! Investing in customized subroutines is an investment in future laziness.\n\nThis also avoids a common form of ugliness seen in many modules: package-level configuration.\nThat is, you might have seen something like the above implemented like so:\n\nuse Data::Analyze qw(analyze);\n$Data::Analyze::defaulttolerance = 0.10;\n$Data::Analyze::defaultpasses = 10;\n\nThis might save time, until you have multiple modules using Data::Analyze. Because there is only\none global configuration, they step on each other's toes and your code begins to have mysterious\nerrors.\n\nGenerators can also allow you to export class methods to be called as subroutines:\n\npackage Data::Methodical;\nuse Sub::Exporter -setup => { exports => { somemethod => \\&curryclass } };\n\nsub curryclass {\nmy ($class, $name) = @;\nsub { $class->$name(@); };\n}\n\nBecause of the way that exporters and Sub::Exporter work, any package that inherits from\nData::Methodical can inherit its exporter and override its \"somemethod\". If a user imports\n\"somemethod\" from that package, he'll receive a subroutine that calls the method on the\nsubclass, rather than on Data::Methodical itself. Keep in mind that if you re-setup\nSub::Exporter in a package that inherits from Data::Methodical you will, of course, be entirely\nreplacing the exporter from Data::Methodical. \"import\" is a method, and is hidden by the same\nmeans as any other method.\n", "subsections": [ { "name": "Other Customizations", "content": "Building custom routines with generators isn't the only way that Sub::Exporters allows the\nimporting code to refine its use of the exported routines. They may also be renamed to avoid\nnaming collisions.\n\nConsider the following code:\n\n# this program determines to which circle of Hell you will be condemned\nuse Morality qw(sin virtue); # for calculating viciousness\nuse Math::Trig qw(:all); # for dealing with circles\n\nThe programmer has inadvertently imported two \"sin\" routines. The solution, in Exporter.pm-based\nmodules, would be to import only one and then call the other by its fully-qualified name.\nAlternately, the importer could write a routine that did so, or could mess about with typeglobs.\n\nHow much easier to write:\n\n# this program determines to which circle of Hell you will be condemned\nuse Morality qw(virtue), sin => { -as => 'offense' };\nuse Math::Trig -all => { -prefix => 'trig' };\n\nand to have at one's disposal \"offense\" and \"trigsin\" -- not to mention \"trigcos\" and\n\"trigtan\".\n" } ] }, "PERL VERSION SUPPORT": { "content": "This module has a long-term perl support period. That means it will not require a version of\nperl released fewer than five years ago.\n\nAlthough it may work on older versions of perl, no guarantee is made that the minimum required\nversion will not be increased. The version may be increased for any reason, and there is no\npromise that patches will be accepted to lower the minimum required perl.\n", "subsections": [] }, "EXPORTER CONFIGURATION": { "content": "You can configure an exporter for your package by using Sub::Exporter like so:\n\npackage Tools;\nuse Sub::Exporter\n-setup => { exports => [ qw(function1 function2 function3) ] };\n\nThis is the simplest way to use the exporter, and is basically equivalent to this:\n\npackage Tools;\nuse base qw(Exporter);\nour @EXPORTOK = qw(function1 function2 function3);\n\nAny basic use of Sub::Exporter will look like this:\n\npackage Tools;\nuse Sub::Exporter -setup => \\%config;\n\nThe following keys are valid in %config:\n\nexports - a list of routines to provide for exporting; each routine may be\nfollowed by generator\ngroups - a list of groups to provide for exporting; each must be followed by\neither (a) a list of exports, possibly with arguments for each\nexport, or (b) a generator\n\ncollectors - a list of names into which values are collected for use in\nroutine generation; each name may be followed by a validator\n\nIn addition to the basic options above, a few more advanced options may be passed:\n\nintolevel - how far up the caller stack to look for a target (default 0)\ninto - an explicit target (package) into which to export routines\n\nIn other words: Sub::Exporter installs a \"import\" routine which, when called, exports routines\nto the calling namespace. The \"into\" and \"intolevel\" options change where those exported\nroutines are installed.\n\ngenerator - a callback used to produce the code that will be installed\ndefault: Sub::Exporter::defaultgenerator\n\ninstaller - a callback used to install the code produced by the generator\ndefault: Sub::Exporter::defaultinstaller\n\nFor information on how these callbacks are used, see the documentation for \"defaultgenerator\"\nand \"defaultinstaller\".\n", "subsections": [ { "name": "Export Configuration", "content": "The \"exports\" list may be provided as an array reference or a hash reference. The list is\nprocessed in such a way that the following are equivalent:\n\n{ exports => [ qw(foo bar baz), quux => \\&quuxgenerator ] }\n\n{ exports =>\n{ foo => undef, bar => undef, baz => undef, quux => \\&quuxgenerator } }\n\nGenerators are code that return coderefs. They are called with four parameters:\n\n$class - the class whose exporter has been called (the exporting class)\n$name - the name of the export for which the routine is being build\n\\%arg - the arguments passed for this export\n\\%col - the collections for this import\n\nGiven the configuration in the \"SYNOPSIS\", the following \"use\" statement:\n\nuse Text::Tweaker\nreformat => { -as => 'makenarrow', width => 33 },\ndefaults => { eol => 'CR' };\n\nwould result in the following call to &buildreformatter:\n\nmy $code = buildreformatter(\n'Text::Tweaker',\n'reformat',\n{ width => 33 }, # note that -as is not passed in\n{ defaults => { eol => 'CR' } },\n);\n\nThe returned coderef ($code) would then be installed as \"makenarrow\" in the calling package.\n\nInstead of providing a coderef in the configuration, a reference to a method name may be\nprovided. This method will then be called on the invocant of the \"import\" method. (In this case,\nwe do not pass the $class parameter, as it would be redundant.)\n" }, { "name": "Group Configuration", "content": "The \"groups\" list can be passed in the same forms as \"exports\". Groups must have values to be\nmeaningful, which may either list exports that make up the group (optionally with arguments) or\nmay provide a way to build the group.\n\nThe simpler case is the first: a group definition is a list of exports. Here's the example that\ncould go in exporter in the \"SYNOPSIS\".\n\ngroups => {\ndefault => [ qw(reformat) ],\nshorteners => [ qw(squish trim) ],\nemailsafe => [\n'indent',\nreformat => { -as => 'emailformat', width => 72 }\n],\n},\n\nGroups are imported by specifying their name prefixed be either a dash or a colon. This line of\ncode would import the \"shorteners\" group:\n\nuse Text::Tweaker qw(-shorteners);\n\nArguments passed to a group when importing are merged into the groups options and passed to any\nrelevant generators. Groups can contain other groups, but looping group structures are ignored.\n\nThe other possible value for a group definition, a coderef, allows one generator to build\nseveral exportable routines simultaneously. This is useful when many routines must share\nenclosed lexical variables. The coderef must return a hash reference. The keys will be used as\nexport names and the values are the subs that will be exported.\n\nThis example shows a simple use of the group generator.\n\npackage Data::Crypto;\nuse Sub::Exporter -setup => { groups => { cipher => \\&buildciphergroup } };\n\nsub buildciphergroup {\nmy ($class, $group, $arg) = @;\nmy ($encode, $decode) = buildcodec($arg->{secret});\nreturn { cipher => $encode, decipher => $decode };\n}\n\nThe \"cipher\" and \"decipher\" routines are built in a group because they are built together by\ncode which encloses their secret in their environment.\n\nDefault Groups\nIf a module that uses Sub::Exporter is \"use\"d with no arguments, it will try to export the group\nnamed \"default\". If that group has not been specifically configured, it will be empty, and\nnothing will happen.\n\nAnother group is also created if not defined: \"all\". The \"all\" group contains all the exports\nfrom the exports list.\n" }, { "name": "Collector Configuration", "content": "The \"collectors\" entry in the exporter configuration gives names which, when found in the import\ncall, have their values collected and passed to every generator.\n\nFor example, the \"buildanalyzer\" generator that we saw above could be rewritten as:\n\nsub buildanalyzer {\nmy ($class, $name, $arg, $col) = @;\n\nreturn sub {\nmy $data = shift;\nmy $tolerance = shift || $arg->{tolerance} || $col->{defaults}{tolerance};\nmy $passes = shift || $arg->{passes} || $col->{defaults}{passes};\n\nanalyze($data, $tolerance, $passes);\n}\n}\n\nThat would allow the importer to specify global defaults for his imports:\n\nuse Data::Analyze\n'analyze',\nanalyze => { tolerance => 0.10, -as => analyze10 },\nanalyze => { tolerance => 0.15, passes => 50, -as => analyze50 },\ndefaults => { passes => 10 };\n\nmy $A = analyze10($data); # equivalent to analyze($data, 0.10, 10);\nmy $C = analyze50($data); # equivalent to analyze($data, 0.15, 50);\nmy $B = analyze($data, 0.20); # equivalent to analyze($data, 0.20, 10);\n\nIf values are provided in the \"collectors\" list during exporter setup, they must be code\nreferences, and are used to validate the importer's values. The validator is called when the\ncollection is found, and if it returns false, an exception is thrown. We could ensure that no\none tries to set a global data default easily:\n\ncollectors => { defaults => sub { return (exists $[0]->{data}) ? 0 : 1 } }\n\nCollector coderefs can also be used as hooks to perform arbitrary actions before anything is\nexported.\n\nWhen the coderef is called, it is passed the value of the collection and a hashref containing\nthe following entries:\n\nname - the name of the collector\nconfig - the exporter configuration (hashref)\nimportargs - the arguments passed to the exporter, sans collections (aref)\nclass - the package on which the importer was called\ninto - the package into which exports will be exported\n\nCollectors with all-caps names (that is, made up of underscore or capital A through Z) are\nreserved for special use. The only currently implemented special collector is \"INIT\", whose hook\n(if present in the exporter configuration) is always run before any other hook.\n" } ] }, "CALLING THE EXPORTER": { "content": "Arguments to the exporter (that is, the arguments after the module name in a \"use\" statement)\nare parsed as follows:\n\nFirst, the collectors gather any collections found in the arguments. Any reference type may be\ngiven as the value for a collector. For each collection given in the arguments, its validator\n(if any) is called.\n\nNext, groups are expanded. If the group is implemented by a group generator, the generator is\ncalled. There are two special arguments which, if given to a group, have special meaning:\n\n-prefix - a string to prepend to any export imported from this group\n-suffix - a string to append to any export imported from this group\n\nFinally, individual export generators are called and all subs, generated or otherwise, are\ninstalled in the calling package. There is only one special argument for export generators:\n\n-as - where to install the exported sub\n\nNormally, \"-as\" will contain an alternate name for the routine. It may, however, contain a\nreference to a scalar. If that is the case, a reference the generated routine will be placed in\nthe scalar referenced by \"-as\". It will not be installed into the calling package.\n", "subsections": [ { "name": "Special Exporter Arguments", "content": "The generated exporter accept some special options, which may be passed as the first argument,\nin a hashref.\n\nThese options are:\n\nintolevel\ninto\ngenerator\ninstaller\n\nThese override the same-named configuration options described in \"EXPORTER CONFIGURATION\".\n" } ] }, "SUBROUTINES": { "content": "setupexporter\nThis routine builds and installs an \"import\" routine. It is called with one argument, a hashref\ncontaining the exporter configuration. Using this, it builds an exporter and installs it into\nthe calling package with the name \"import.\" In addition to the normal exporter configuration, a\nfew named arguments may be passed in the hashref:\n\ninto - into what package should the exporter be installed\nintolevel - into what level up the stack should the exporter be installed\nas - what name should the installed exporter be given\n\nBy default the exporter is installed with the name \"import\" into the immediate caller of\n\"setupexporter\". In other words, if your package calls \"setupexporter\" without providing any\nof the three above arguments, it will have an \"import\" routine installed.\n\nProviding both \"into\" and \"intolevel\" will cause an exception to be thrown.\n\nThe exporter is built by \"buildexporter\".\n\nbuildexporter\nGiven a standard exporter configuration, this routine builds and returns an exporter -- that is,\na subroutine that can be installed as a class method to perform exporting on request.\n\nUsually, this method is called by \"setupexporter\", which then installs the exporter as a\npackage's import routine.\n\ndefaultgenerator\nThis is Sub::Exporter's default generator. It takes bits of configuration that have been\ngathered during the import and turns them into a coderef that can be installed.\n\nmy $code = defaultgenerator(\\%arg);\n\nPassed arguments are:\n\nclass - the class on which the import method was called\nname - the name of the export being generated\narg - the arguments to the generator\ncol - the collections\n\ngenerator - the generator to be used to build the export (code or scalar ref)\n\ndefaultinstaller\nThis is Sub::Exporter's default installer. It does what Sub::Exporter promises: it installs code\ninto the target package.\n\ndefaultinstaller(\\%arg, \\@toexport);\n\nPassed arguments are:\n\ninto - the package into which exports should be delivered\n\n@toexport is a list of name/value pairs. The default exporter assigns code (the values) to\nnamed slots (the names) in the given package. If the name is a scalar reference, the scalar\nreference is made to point to the code reference instead.\n", "subsections": [] }, "EXPORTS": { "content": "Sub::Exporter also offers its own exports: the \"setupexporter\" and \"buildexporter\" routines\ndescribed above. It also provides a special \"setup\" collector, which will set up an exporter\nusing the parameters passed to it.\n\nNote that the \"setup\" collector (seen in examples like the \"SYNOPSIS\" above) uses\n\"buildexporter\", not \"setupexporter\". This means that the special arguments like \"into\" and\n\"as\" for \"setupexporter\" are not accepted here. Instead, you may write something like:\n\nuse Sub::Exporter\n{ into => 'Target::Package' },\n-setup => {\n-as => 'doimport',\nexports => [ ... ],\n}\n;\n\nFinding a good reason for wanting to do this is left as an exercise for the reader.\n", "subsections": [] }, "COMPARISONS": { "content": "There are a whole mess of exporters on the CPAN. The features included in Sub::Exporter set it\napart from any existing Exporter. Here's a summary of some other exporters and how they compare.\n\n* Exporter and co.\n\nThis is the standard Perl exporter. Its interface is a little clunky, but it's fast and\nubiquitous. It can do some things that Sub::Exporter can't: it can export things other than\nroutines, it can import \"everything in this group except this symbol,\" and some other more\nesoteric things. These features seem to go nearly entirely unused.\n\nIt always exports things exactly as they appear in the exporting module; it can't rename or\ncustomize routines. Its groups (\"tags\") can't be nested.\n\nExporter::Lite is a whole lot like Exporter, but it does significantly less: it supports\nexporting symbols, but not groups, pattern matching, or negation.\n\nThe fact that Sub::Exporter can't export symbols other than subroutines is a good idea, not\na missing feature.\n\nFor simple uses, setting up Sub::Exporter is about as easy as Exporter. For complex uses,\nSub::Exporter makes hard things possible, which would not be possible with Exporter.\n\nWhen using a module that uses Sub::Exporter, users familiar with Exporter will probably see\nno difference in the basics. These two lines do about the same thing in whether the\nexporting module uses Exporter or Sub::Exporter.\n\nuse Some::Module qw(foo bar baz);\nuse Some::Module qw(foo :bar baz);\n\nThe definition for exporting in Exporter.pm might look like this:\n\npackage Some::Module;\nuse base qw(Exporter);\nour @EXPORTOK = qw(foo bar baz quux);\nour %EXPORTTAGS = (bar => [ qw(bar baz) ]);\n\nUsing Sub::Exporter, it would look like this:\n\npackage Some::Module;\nuse Sub::Exporter -setup => {\nexports => [ qw(foo bar baz quux) ],\ngroups => { bar => [ qw(bar baz) ]}\n};\n\nSub::Exporter respects inheritance, so that a package may export inherited routines, and\nwill export the most inherited version. Exporting methods without currying away the invocant\nis a bad idea, but Sub::Exporter allows you to do just that -- and anyway, there are other\nuses for this feature, like packages of exported subroutines which use inheritance\nspecifically to allow more specialized, but similar, packages.\n\nExporter::Easy provides a wrapper around the standard Exporter. It makes it simpler to build\ngroups, but doesn't provide any more functionality. Because it is a front-end to Exporter,\nit will store your exporter's configuration in global package variables.\n\n* Attribute-Based Exporters\n\nSome exporters use attributes to mark variables to export. Exporter::Simple supports\nexporting any kind of symbol, and supports groups. Using a module like Exporter or\nSub::Exporter, it's easy to look at one place and see what is exported, but it's impossible\nto look at a variable definition and see whether it is exported by that alone.\nExporter::Simple makes this trade in reverse: each variable's declaration includes its\nexport definition, but there is no one place to look to find a manifest of exports.\n\nMore importantly, Exporter::Simple does not add any new features to those of Exporter. In\nfact, like Exporter::Easy, it is just a front-end to Exporter, so it ends up storing its\nconfiguration in global package variables. (This means that there is one place to look for\nyour exporter's manifest, actually. You can inspect the @EXPORT package variables, and other\nrelated package variables, at runtime.)\n\nPerl6::Export isn't actually attribute based, but looks similar. Its syntax is borrowed from\nPerl 6, and implemented by a source filter. It is a prototype of an interface that is still\nbeing designed. It should probably be avoided for production work. On the other hand,\nPerl6::Export::Attrs implements Perl 6-like exporting, but translates it into Perl 5 by\nproviding attributes.\n\n* Other Exporters\n\nExporter::Renaming wraps the standard Exporter to allow it to export symbols with changed\nnames.\n\nClass::Exporter performs a special kind of routine generation, giving each importing package\nan instance of your class, and then exporting the instance's methods as normal routines.\n(Sub::Exporter, of course, can easily emulate this behavior, as shown above.)\n\nExporter::Tidy implements a form of renaming (using its \"map\" argument) and of prefixing,\nand implements groups. It also avoids using package variables for its configuration.\n", "subsections": [] }, "TODO": { "content": "* write a set of longer, more demonstrative examples\n\n* solidify the \"custom exporter\" interface (see &defaultexporter)\n\n* add an \"always\" group\n", "subsections": [] }, "THANKS": { "content": "Hans Dieter Pearcey provided helpful advice while I was writing Sub::Exporter. Ian Langworth and\nShawn Sorichetti asked some good questions and helped me improve my documentation quite a bit.\nYuval Kogman helped me find a bunch of little problems.\n\nThanks, friends!\n", "subsections": [] }, "BUGS": { "content": "Please report any bugs or feature requests through the web interface at . I\nwill be notified, and then you'll automatically be notified of progress on your bug as I make\nchanges.\n", "subsections": [] }, "AUTHOR": { "content": "Ricardo Signes \n", "subsections": [] }, "CONTRIBUTORS": { "content": "* David Steinbrunner \n\n* everybody \n\n* George Hartzell \n\n* Hans Dieter Pearcey \n\n* Karen Etheridge \n", "subsections": [] }, "COPYRIGHT AND LICENSE": { "content": "This software is copyright (c) 2007 by Ricardo Signes.\n\nThis is free software; you can redistribute it and/or modify it under the same terms as the Perl\n5 programming language system itself.\n", "subsections": [] } } } }