{
    "content": [
        {
            "type": "text",
            "text": "# perlmod(1) (man)\n\n**Summary:** perlmod - Perl modules (packages and symbol tables)\n\n## Section Outline\n\n- **NAME** (2 lines)\n- **DESCRIPTION** (1 lines) — 7 subsections\n  - Is this the document you were after? (11 lines)\n  - Packages (77 lines)\n  - Symbol Tables (149 lines)\n  - BEGIN, UNITCHECK, CHECK, INIT and END (101 lines)\n  - Perl Classes (7 lines)\n  - Perl Modules (138 lines)\n  - Making your module threadsafe (32 lines)\n- **SEE ALSO** (10 lines)\n\n## Full Content\n\n### NAME\n\nperlmod - Perl modules (packages and symbol tables)\n\n### DESCRIPTION\n\n#### Is this the document you were after?\n\nThere are other documents which might contain the information that you're looking for:\n\nThis doc\nPerl's packages, namespaces, and some info on classes.\n\nperlnewmod\nTutorial on making a new module.\n\nperlmodstyle\nBest practices for making a new module.\n\n#### Packages\n\nUnlike Perl 4, in which all the variables were dynamic and shared one global name space,\ncausing maintainability problems, Perl 5 provides two mechanisms for protecting code from\nhaving its variables stomped on by other code: lexically scoped variables created with \"my\"\nor \"state\" and namespaced global variables, which are exposed via the \"vars\" pragma, or the\n\"our\" keyword. Any global variable is considered to be part of a namespace and can be\naccessed via a \"fully qualified form\".  Conversely, any lexically scoped variable is\nconsidered to be part of that lexical-scope, and does not have a \"fully qualified form\".\n\nIn perl namespaces are called \"packages\" and the \"package\" declaration tells the compiler\nwhich namespace to prefix to \"our\" variables and unqualified dynamic names.  This both\nprotects against accidental stomping and provides an interface for deliberately clobbering\nglobal dynamic variables declared and used in other scopes or packages, when that is what you\nwant to do.\n\nThe scope of the \"package\" declaration is from the declaration itself through the end of the\nenclosing block, \"eval\", or file, whichever comes first (the same scope as the my(), our(),\nstate(), and local() operators, and also the effect of the experimental \"reference aliasing,\"\nwhich may change), or until the next \"package\" declaration.  Unqualified dynamic identifiers\nwill be in this namespace, except for those few identifiers that, if unqualified, default to\nthe main package instead of the current one as described below.  A \"package\" statement\naffects only dynamic global symbols, including subroutine names, and variables you've used\nlocal() on, but not lexical variables created with my(), our() or state().\n\nTypically, a \"package\" statement is the first declaration in a file included in a program by\none of the \"do\", \"require\", or \"use\" operators.  You can switch into a package in more than\none place: \"package\" has no effect beyond specifying which symbol table the compiler will use\nfor dynamic symbols for the rest of that block or until the next \"package\" statement.  You\ncan refer to variables and filehandles in other packages by prefixing the identifier with the\npackage name and a double colon: $Package::Variable.  If the package name is null, the \"main\"\npackage is assumed.  That is, $::sail is equivalent to $main::sail.\n\nThe old package delimiter was a single quote, but double colon is now the preferred\ndelimiter, in part because it's more readable to humans, and in part because it's more\nreadable to emacs macros.  It also makes C++ programmers feel like they know what's going\non--as opposed to using the single quote as separator, which was there to make Ada\nprogrammers feel like they knew what was going on.  Because the old-fashioned syntax is still\nsupported for backwards compatibility, if you try to use a string like \"This is $owner's\nhouse\", you'll be accessing $owner::s; that is, the $s variable in package \"owner\", which is\nprobably not what you meant.  Use braces to disambiguate, as in \"This is ${owner}'s house\".\n\nPackages may themselves contain package separators, as in $OUTER::INNER::var.  This implies\nnothing about the order of name lookups, however.  There are no relative packages: all\nsymbols are either local to the current package, or must be fully qualified from the outer\npackage name down.  For instance, there is nowhere within package \"OUTER\" that $INNER::var\nrefers to $OUTER::INNER::var.  \"INNER\" refers to a totally separate global package. The\ncustom of treating package names as a hierarchy is very strong, but the language in no way\nenforces it.\n\nOnly identifiers starting with letters (or underscore) are stored in a package's symbol\ntable.  All other symbols are kept in package \"main\", including all punctuation variables,\nlike $.  In addition, when unqualified, the identifiers STDIN, STDOUT, STDERR, ARGV,\nARGVOUT, ENV, INC, and SIG are forced to be in package \"main\", even when used for other\npurposes than their built-in ones.  If you have a package called \"m\", \"s\", or \"y\", then you\ncan't use the qualified form of an identifier because it would be instead interpreted as a\npattern match, a substitution, or a transliteration.\n\nVariables beginning with underscore used to be forced into package main, but we decided it\nwas more useful for package writers to be able to use leading underscore to indicate private\nvariables and method names.  However, variables and functions named with a single \"\", such\nas $ and \"sub \", are still forced into the package \"main\".  See also \"The Syntax of\nVariable Names\" in perlvar.\n\n\"eval\"ed strings are compiled in the package in which the eval() was compiled.  (Assignments\nto $SIG{}, however, assume the signal handler specified is in the \"main\" package.  Qualify\nthe signal handler name if you wish to have a signal handler in a package.)  For an example,\nexamine perldb.pl in the Perl library.  It initially switches to the \"DB\" package so that the\ndebugger doesn't interfere with variables in the program you are trying to debug.  At various\npoints, however, it temporarily switches back to the \"main\" package to evaluate various\nexpressions in the context of the \"main\" package (or wherever you came from).  See perldebug.\n\nThe special symbol \"PACKAGE\" contains the current package, but cannot (easily) be used to\nconstruct variable names. After \"my($foo)\" has hidden package variable $foo, it can still be\naccessed, without knowing what package you are in, as \"${PACKAGE.'::foo'}\".\n\nSee perlsub for other scoping issues related to my() and local(), and perlref regarding\nclosures.\n\n#### Symbol Tables\n\nThe symbol table for a package happens to be stored in the hash of that name with two colons\nappended.  The main symbol table's name is thus %main::, or %:: for short.  Likewise the\nsymbol table for the nested package mentioned earlier is named %OUTER::INNER::.\n\nThe value in each entry of the hash is what you are referring to when you use the *name\ntypeglob notation.\n\nlocal *main::foo    = *main::bar;\n\nYou can use this to print out all the variables in a package, for instance.  The standard but\nantiquated dumpvar.pl library and the CPAN module Devel::Symdump make use of this.\n\nThe results of creating new symbol table entries directly or modifying any entries that are\nnot already typeglobs are undefined and subject to change between releases of perl.\n\nAssignment to a typeglob performs an aliasing operation, i.e.,\n\n*dick = *richard;\n\ncauses variables, subroutines, formats, and file and directory handles accessible via the\nidentifier \"richard\" also to be accessible via the identifier \"dick\".  If you want to alias\nonly a particular variable or subroutine, assign a reference instead:\n\n*dick = \\$richard;\n\nWhich makes $richard and $dick the same variable, but leaves @richard and @dick as separate\narrays.  Tricky, eh?\n\nThere is one subtle difference between the following statements:\n\n*foo = *bar;\n*foo = \\$bar;\n\n\"*foo = *bar\" makes the typeglobs themselves synonymous while \"*foo = \\$bar\" makes the SCALAR\nportions of two distinct typeglobs refer to the same scalar value. This means that the\nfollowing code:\n\n$bar = 1;\n*foo = \\$bar;       # Make $foo an alias for $bar\n\n{\nlocal $bar = 2; # Restrict changes to block\nprint $foo;     # Prints '1'!\n}\n\nWould print '1', because $foo holds a reference to the original $bar. The one that was\nstuffed away by \"local()\" and which will be restored when the block ends. Because variables\nare accessed through the typeglob, you can use \"*foo = *bar\" to create an alias which can be\nlocalized. (But be aware that this means you can't have a separate @foo and @bar, etc.)\n\nWhat makes all of this important is that the Exporter module uses glob aliasing as the\nimport/export mechanism. Whether or not you can properly localize a variable that has been\nexported from a module depends on how it was exported:\n\n@EXPORT = qw($FOO); # Usual form, can't be localized\n@EXPORT = qw(*FOO); # Can be localized\n\nYou can work around the first case by using the fully qualified name ($Package::FOO) where\nyou need a local value, or by overriding it by saying \"*FOO = *Package::FOO\" in your script.\n\nThe \"*x = \\$y\" mechanism may be used to pass and return cheap references into or from\nsubroutines if you don't want to copy the whole thing.  It only works when assigning to\ndynamic variables, not lexicals.\n\n%somehash = ();                    # can't be my()\n*somehash = fn( \\%anotherhash );\nsub fn {\nlocal *hashsym = shift;\n# now use %hashsym normally, and you\n# will affect the caller's %anotherhash\nmy %nhash = (); # do what you want\nreturn \\%nhash;\n}\n\nOn return, the reference will overwrite the hash slot in the symbol table specified by the\n*somehash typeglob.  This is a somewhat tricky way of passing around references cheaply when\nyou don't want to have to remember to dereference variables explicitly.\n\nAnother use of symbol tables is for making \"constant\" scalars.\n\n*PI = \\3.14159265358979;\n\nNow you cannot alter $PI, which is probably a good thing all in all.  This isn't the same as\na constant subroutine, which is subject to optimization at compile-time.  A constant\nsubroutine is one prototyped to take no arguments and to return a constant expression.  See\nperlsub for details on these.  The \"use constant\" pragma is a convenient shorthand for these.\n\nYou can say *foo{PACKAGE} and *foo{NAME} to find out what name and package the *foo symbol\ntable entry comes from.  This may be useful in a subroutine that gets passed typeglobs as\narguments:\n\nsub identifytypeglob {\nmy $glob = shift;\nprint 'You gave me ', *{$glob}{PACKAGE},\n'::', *{$glob}{NAME}, \"\\n\";\n}\nidentifytypeglob *foo;\nidentifytypeglob *bar::baz;\n\nThis prints\n\nYou gave me main::foo\nYou gave me bar::baz\n\nThe *foo{THING} notation can also be used to obtain references to the individual elements of\n*foo.  See perlref.\n\nSubroutine definitions (and declarations, for that matter) need not necessarily be situated\nin the package whose symbol table they occupy.  You can define a subroutine outside its\npackage by explicitly qualifying the name of the subroutine:\n\npackage main;\nsub Somepackage::foo { ... }   # &foo defined in Somepackage\n\nThis is just a shorthand for a typeglob assignment at compile time:\n\nBEGIN { *Somepackage::foo = sub { ... } }\n\nand is not the same as writing:\n\n{\npackage Somepackage;\nsub foo { ... }\n}\n\nIn the first two versions, the body of the subroutine is lexically in the main package, not\nin Somepackage. So something like this:\n\npackage main;\n\n$Somepackage::name = \"fred\";\n$main::name = \"barney\";\n\nsub Somepackage::foo {\nprint \"in \", PACKAGE, \": \\$name is '$name'\\n\";\n}\n\nSomepackage::foo();\n\nprints:\n\nin main: $name is 'barney'\n\nrather than:\n\nin Somepackage: $name is 'fred'\n\nThis also has implications for the use of the SUPER:: qualifier (see perlobj).\n\n#### BEGIN, UNITCHECK, CHECK, INIT and END\n\nFive specially named code blocks are executed at the beginning and at the end of a running\nPerl program.  These are the \"BEGIN\", \"UNITCHECK\", \"CHECK\", \"INIT\", and \"END\" blocks.\n\nThese code blocks can be prefixed with \"sub\" to give the appearance of a subroutine (although\nthis is not considered good style).  One should note that these code blocks don't really\nexist as named subroutines (despite their appearance). The thing that gives this away is the\nfact that you can have more than one of these code blocks in a program, and they will get all\nexecuted at the appropriate moment.  So you can't execute any of these code blocks by name.\n\nA \"BEGIN\" code block is executed as soon as possible, that is, the moment it is completely\ndefined, even before the rest of the containing file (or string) is parsed.  You may have\nmultiple \"BEGIN\" blocks within a file (or eval'ed string); they will execute in order of\ndefinition.  Because a \"BEGIN\" code block executes immediately, it can pull in definitions of\nsubroutines and such from other files in time to be visible to the rest of the compile and\nrun time.  Once a \"BEGIN\" has run, it is immediately undefined and any code it used is\nreturned to Perl's memory pool.\n\nAn \"END\" code block is executed as late as possible, that is, after perl has finished running\nthe program and just before the interpreter is being exited, even if it is exiting as a\nresult of a die() function.  (But not if it's morphing into another program via \"exec\", or\nbeing blown out of the water by a signal--you have to trap that yourself (if you can).)  You\nmay have multiple \"END\" blocks within a file--they will execute in reverse order of\ndefinition; that is: last in, first out (LIFO).  \"END\" blocks are not executed when you run\nperl with the \"-c\" switch, or if compilation fails.\n\nNote that \"END\" code blocks are not executed at the end of a string \"eval()\": if any \"END\"\ncode blocks are created in a string \"eval()\", they will be executed just as any other \"END\"\ncode block of that package in LIFO order just before the interpreter is being exited.\n\nInside an \"END\" code block, $? contains the value that the program is going to pass to\n\"exit()\".  You can modify $? to change the exit value of the program.  Beware of changing $?\nby accident (e.g. by running something via \"system\").\n\nInside of a \"END\" block, the value of \"${^GLOBALPHASE}\" will be \"END\".\n\n\"UNITCHECK\", \"CHECK\" and \"INIT\" code blocks are useful to catch the transition between the\ncompilation phase and the execution phase of the main program.\n\n\"UNITCHECK\" blocks are run just after the unit which defined them has been compiled.  The\nmain program file and each module it loads are compilation units, as are string \"eval\"s, run-\ntime code compiled using the \"(?{ })\" construct in a regex, calls to \"do FILE\", \"require\nFILE\", and code after the \"-e\" switch on the command line.\n\n\"BEGIN\" and \"UNITCHECK\" blocks are not directly related to the phase of the interpreter.\nThey can be created and executed during any phase.\n\n\"CHECK\" code blocks are run just after the initial Perl compile phase ends and before the run\ntime begins, in LIFO order.  \"CHECK\" code blocks are used in the Perl compiler suite to save\nthe compiled state of the program.\n\nInside of a \"CHECK\" block, the value of \"${^GLOBALPHASE}\" will be \"CHECK\".\n\n\"INIT\" blocks are run just before the Perl runtime begins execution, in \"first in, first out\"\n(FIFO) order.\n\nInside of an \"INIT\" block, the value of \"${^GLOBALPHASE}\" will be \"INIT\".\n\nThe \"CHECK\" and \"INIT\" blocks in code compiled by \"require\", string \"do\", or string \"eval\"\nwill not be executed if they occur after the end of the main compilation phase; that can be a\nproblem in modperl and other persistent environments which use those functions to load code\nat runtime.\n\nWhen you use the -n and -p switches to Perl, \"BEGIN\" and \"END\" work just as they do in awk,\nas a degenerate case.  Both \"BEGIN\" and \"CHECK\" blocks are run when you use the -c switch for\na compile-only syntax check, although your main code is not.\n\nThe begincheck program makes it all clear, eventually:\n\n#!/usr/bin/perl\n\n# begincheck\n\nprint         \"10. Ordinary code runs at runtime.\\n\";\n\nEND { print   \"16.   So this is the end of the tale.\\n\" }\nINIT { print  \" 7. INIT blocks run FIFO just before runtime.\\n\" }\nUNITCHECK {\nprint       \" 4.   And therefore before any CHECK blocks.\\n\"\n}\nCHECK { print \" 6.   So this is the sixth line.\\n\" }\n\nprint         \"11.   It runs in order, of course.\\n\";\n\nBEGIN { print \" 1. BEGIN blocks run FIFO during compilation.\\n\" }\nEND { print   \"15.   Read perlmod for the rest of the story.\\n\" }\nCHECK { print \" 5. CHECK blocks run LIFO after all compilation.\\n\" }\nINIT { print  \" 8.   Run this again, using Perl's -c switch.\\n\" }\n\nprint         \"12.   This is anti-obfuscated code.\\n\";\n\nEND { print   \"14. END blocks run LIFO at quitting time.\\n\" }\nBEGIN { print \" 2.   So this line comes out second.\\n\" }\nUNITCHECK {\nprint \" 3. UNITCHECK blocks run LIFO after each file is compiled.\\n\"\n}\nINIT { print  \" 9.   You'll see the difference right away.\\n\" }\n\nprint         \"13.   It only looks like it should be confusing.\\n\";\n\nEND\n\n#### Perl Classes\n\nThere is no special class syntax in Perl, but a package may act as a class if it provides\nsubroutines to act as methods.  Such a package may also derive some of its methods from\nanother class (package) by listing the other package name(s) in its global @ISA array (which\nmust be a package global, not a lexical).\n\nFor more on this, see perlootut and perlobj.\n\n#### Perl Modules\n\nA module is just a set of related functions in a library file, i.e., a Perl package with the\nsame name as the file.  It is specifically designed to be reusable by other modules or\nprograms.  It may do this by providing a mechanism for exporting some of its symbols into the\nsymbol table of any package using it, or it may function as a class definition and make its\nsemantics available implicitly through method calls on the class and its objects, without\nexplicitly exporting anything.  Or it can do a little of both.\n\nFor example, to start a traditional, non-OO module called Some::Module, create a file called\nSome/Module.pm and start with this template:\n\npackage Some::Module;  # assumes Some/Module.pm\n\nuse strict;\nuse warnings;\n\n# Get the import method from Exporter to export functions and\n# variables\nuse Exporter 5.57 'import';\n\n# set the version for version checking\nour $VERSION     = '1.00';\n\n# Functions and variables which are exported by default\nour @EXPORT      = qw(func1 func2);\n\n# Functions and variables which can be optionally exported\nour @EXPORTOK   = qw($Var1 %Hashit func3);\n\n# exported package globals go here\nour $Var1    = '';\nour %Hashit  = ();\n\n# non-exported package globals go here\n# (they are still accessible as $Some::Module::stuff)\nour @more    = ();\nour $stuff   = '';\n\n# file-private lexicals go here, before any functions which use them\nmy $privvar    = '';\nmy %secrethash = ();\n\n# here's a file-private function as a closure,\n# callable as $privfunc->();\nmy $privfunc = sub {\n...\n};\n\n# make all your functions, whether exported or not;\n# remember to put something interesting in the {} stubs\nsub func1      { ... }\nsub func2      { ... }\n\n# this one isn't always exported, but could be called directly\n# as Some::Module::func3()\nsub func3      { ... }\n\nEND { ... }       # module clean-up code here (global destructor)\n\n1;  # don't forget to return a true value from the file\n\nThen go on to declare and use your variables in functions without any qualifications.  See\nExporter and the perlmodlib for details on mechanics and style issues in module creation.\n\nPerl modules are included into your program by saying\n\nuse Module;\n\nor\n\nuse Module LIST;\n\nThis is exactly equivalent to\n\nBEGIN { require 'Module.pm'; 'Module'->import; }\n\nor\n\nBEGIN { require 'Module.pm'; 'Module'->import( LIST ); }\n\nAs a special case\n\nuse Module ();\n\nis exactly equivalent to\n\nBEGIN { require 'Module.pm'; }\n\nAll Perl module files have the extension .pm.  The \"use\" operator assumes this so you don't\nhave to spell out \"Module.pm\" in quotes.  This also helps to differentiate new modules from\nold .pl and .ph files.  Module names are also capitalized unless they're functioning as\npragmas; pragmas are in effect compiler directives, and are sometimes called \"pragmatic\nmodules\" (or even \"pragmata\" if you're a classicist).\n\nThe two statements:\n\nrequire SomeModule;\nrequire \"SomeModule.pm\";\n\ndiffer from each other in two ways.  In the first case, any double colons in the module name,\nsuch as \"Some::Module\", are translated into your system's directory separator, usually \"/\".\nThe second case does not, and would have to be specified literally.  The other difference is\nthat seeing the first \"require\" clues in the compiler that uses of indirect object notation\ninvolving \"SomeModule\", as in \"$ob = purge SomeModule\", are method calls, not function calls.\n(Yes, this really can make a difference.)\n\nBecause the \"use\" statement implies a \"BEGIN\" block, the importing of semantics happens as\nsoon as the \"use\" statement is compiled, before the rest of the file is compiled.  This is\nhow it is able to function as a pragma mechanism, and also how modules are able to declare\nsubroutines that are then visible as list or unary operators for the rest of the current\nfile.  This will not work if you use \"require\" instead of \"use\".  With \"require\" you can get\ninto this problem:\n\nrequire Cwd;                # make Cwd:: accessible\n$here = Cwd::getcwd();\n\nuse Cwd;                    # import names from Cwd::\n$here = getcwd();\n\nrequire Cwd;                # make Cwd:: accessible\n$here = getcwd();           # oops! no main::getcwd()\n\nIn general, \"use Module ()\" is recommended over \"require Module\", because it determines\nmodule availability at compile time, not in the middle of your program's execution.  An\nexception would be if two modules each tried to \"use\" each other, and each also called a\nfunction from that other module.  In that case, it's easy to use \"require\" instead.\n\nPerl packages may be nested inside other package names, so we can have package names\ncontaining \"::\".  But if we used that package name directly as a filename it would make for\nunwieldy or impossible filenames on some systems.  Therefore, if a module's name is, say,\n\"Text::Soundex\", then its definition is actually found in the library file Text/Soundex.pm.\n\nPerl modules always have a .pm file, but there may also be dynamically linked executables\n(often ending in .so) or autoloaded subroutine definitions (often ending in .al) associated\nwith the module.  If so, these will be entirely transparent to the user of the module.  It is\nthe responsibility of the .pm file to load (or arrange to autoload) any additional\nfunctionality.  For example, although the POSIX module happens to do both dynamic loading and\nautoloading, the user can say just \"use POSIX\" to get it all.\n\n#### Making your module threadsafe\n\nPerl supports a type of threads called interpreter threads (ithreads).  These threads can be\nused explicitly and implicitly.\n\nIthreads work by cloning the data tree so that no data is shared between different threads.\nThese threads can be used by using the \"threads\" module or by doing fork() on win32 (fake\nfork() support). When a thread is cloned all Perl data is cloned, however non-Perl data\ncannot be cloned automatically.  Perl after 5.8.0 has support for the \"CLONE\" special\nsubroutine.  In \"CLONE\" you can do whatever you need to do, like for example handle the\ncloning of non-Perl data, if necessary.  \"CLONE\" will be called once as a class method for\nevery package that has it defined (or inherits it).  It will be called in the context of the\nnew thread, so all modifications are made in the new area.  Currently CLONE is called with no\nparameters other than the invocant package name, but code should not assume that this will\nremain unchanged, as it is likely that in future extra parameters will be passed in to give\nmore information about the state of cloning.\n\nIf you want to CLONE all objects you will need to keep track of them per package. This is\nsimply done using a hash and Scalar::Util::weaken().\n\nPerl after 5.8.7 has support for the \"CLONESKIP\" special subroutine.  Like \"CLONE\",\n\"CLONESKIP\" is called once per package; however, it is called just before cloning starts,\nand in the context of the parent thread. If it returns a true value, then no objects of that\nclass will be cloned; or rather, they will be copied as unblessed, undef values.  For\nexample: if in the parent there are two references to a single blessed hash, then in the\nchild there will be two references to a single undefined scalar value instead.  This provides\na simple mechanism for making a module threadsafe; just add \"sub CLONESKIP { 1 }\" at the top\nof the class, and \"DESTROY()\" will now only be called once per object. Of course, if the\nchild thread needs to make use of the objects, then a more sophisticated approach is needed.\n\nLike \"CLONE\", \"CLONESKIP\" is currently called with no parameters other than the invocant\npackage name, although that may change. Similarly, to allow for future expansion, the return\nvalue should be a single 0 or 1 value.\n\n### SEE ALSO\n\nSee perlmodlib for general style issues related to building Perl modules and classes, as well\nas descriptions of the standard library and CPAN, Exporter for how Perl's standard\nimport/export mechanism works, perlootut and perlobj for in-depth information on creating\nclasses, perlobj for a hard-core reference document on objects, perlsub for an explanation of\nfunctions and scoping, and perlxstut and perlguts for more information on writing extension\nmodules.\n\n\n\nperl v5.34.0                                 2025-07-25                                   PERLMOD(1)\n\n"
        }
    ],
    "structuredContent": {
        "command": "perlmod",
        "section": "1",
        "mode": "man",
        "summary": "perlmod - Perl modules (packages and symbol tables)",
        "synopsis": null,
        "tldr_summary": null,
        "tldr_examples": [],
        "tldr_source": null,
        "flags": [],
        "examples": [],
        "see_also": [],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "DESCRIPTION",
                "lines": 1,
                "subsections": [
                    {
                        "name": "Is this the document you were after?",
                        "lines": 11
                    },
                    {
                        "name": "Packages",
                        "lines": 77
                    },
                    {
                        "name": "Symbol Tables",
                        "lines": 149
                    },
                    {
                        "name": "BEGIN, UNITCHECK, CHECK, INIT and END",
                        "lines": 101
                    },
                    {
                        "name": "Perl Classes",
                        "lines": 7
                    },
                    {
                        "name": "Perl Modules",
                        "lines": 138
                    },
                    {
                        "name": "Making your module threadsafe",
                        "lines": 32
                    }
                ]
            },
            {
                "name": "SEE ALSO",
                "lines": 10,
                "subsections": []
            }
        ]
    }
}