package GoodStuff;
use SelfLoader;
[initializing code]
__DATA__
sub {...};
This module is used for delayed loading of Perl functions
that (unlike AutoLoader functions) are packaged within your script file.
This gives the
appearance
of faster loading.
In the example above, SelfLoader tells its user (GoodStuff) that
functions in the GoodStuff package are to
be autoloaded from after the
__DATA__
token.
The
__DATA__
token tells Perl that the code
for compilation is finished. Everything after the
__DATA__
token is available for reading via
the filehandle
GoodStuff::DATA
, where
GoodStuff is the name of the current package when the
__DATA__
token is reached. This token works
just the same as
__END__
does in package
main, except that data after
__END__
is
retrievable only in package main, whereas data after
__DATA__
is retrievable in whatever the
current package is.
Note that it is possible to have
__DATA__
tokens in the same package in multiple files, and that the last
__DATA__
token in a given package that is
encountered by the compiler is the one accessible by the filehandle. That is,
whenever the
__DATA__
token is parsed, any
DATA
filehandle previously open in the current package
(opened in a different file, presumably) is closed so that the new one can be
opened. (This also applies to
__END__
and the
main::DATA
filehandle:
main::DATA
is reopened whenever
__END__
is encountered, so
any former association is lost.)
The SelfLoader will read from the
GoodStuff::DATA
filehandle
to get definitions for functions placed after
__DATA__
, and then
eval
the requested
subroutine the first time
it's called. The costs
are the one-time parsing of the data after
__DATA__
, and a load
delay for the first call
of any autoloaded function. The benefits are a speeded up
compilation phase, with no need to load functions that are never used.
You can use
__END__
after
__DATA__
. The SelfLoader will stop reading
from
DATA
if it encounters the
__END__
token, just as you might expect. If
the
__END__
token is present, and is followed
by the token
DATA
, then the SelfLoader leaves the
GoodStuff::DATA
filehandle open on the line after that token.
The SelfLoader exports the
AUTOLOAD
subroutine to the package using the
SelfLoader, and this triggers the automatic loading of an undefined
subroutine out of its
DATA
portion the first time that subroutine is
called.
There is no advantage to putting subroutines that will always
be called after the
__DATA__
token.
A
my $pack_lexical
statement makes the variable
$pack_lexical
visible
only
up to the
__DATA__
token. That means that subroutines
declared elsewhere cannot see lexical variables. Specifically, autoloaded
functions cannot see such lexicals (this applies to both the SelfLoader and
the Autoloader). The
use vars
pragma (see later in this
chapter) provides a way to declare package-level globals that will be visible to
autoloaded routines.
The SelfLoader can replace the AutoLoader - just change
use AutoLoader
to
use SelfLoader
[
]
and the
__END__
token to
__DATA__
.
There is no need to inherit from the SelfLoader.
The SelfLoader works similarly to the AutoLoader, but picks up the subroutine
definitions from after the
__DATA__
instead
of in the
lib/auto/
directory. SelfLoader needs less
maintenance at the time the module is installed, since there's no need to run
AutoSplit. And it can run faster at load time because it doesn't need to keep
opening and closing files to load subroutines. On the other hand, it can run
slower because it needs to parse the code after the
__DATA__
. Details of the AutoLoader and
another view of these distinctions can be found in that module's documentation.
(This section is only relevant if you want to use
the
GoodStuff::DATA
together with the SelfLoader.)
The SelfLoader reads from wherever the current position of the
GoodStuff::DATA
filehandle is, until EOF or the
__END__
token. This means that if you want
to use that filehandle (and
only
if you want to), you
should either
-
Put all your subroutine declarations immediately
after the
__DATA__
token and put your own data after those
declarations, using the
__END__
token to mark
the end of subroutine
declarations. You must also ensure that the SelfLoader first reads its
stubs by calling
SelfLoader->load_stubs();
, or by using a function
which is selfloaded; or
You could even conceivably do both.
This section is only relevant if your module is a class, and has methods
that could be inherited.
A subroutine stub (or forward declaration) looks like:
sub
stub
;
That is, it is a subroutine declaration without the body of the subroutine. For
modules that aren't classes, there is no real need for stubs as far as
autoloading is concerned.
For modules that
are
classes, and need to handle inherited
methods, stubs are needed to ensure that the method inheritance mechanism works
properly. You can load the stubs into the module at
require
time, by adding the statement
SelfLoader->load_stubs();
to the module to do this.
The alternative is to put the stubs in before the
__DATA__
token before releasing the module,
and for this purpose the Devel::SelfStubber module is available. However this
does require the extra step of ensuring that the stubs are in the module. If
you do this, we strongly recommended that you do it before releasing the module
and
not
at install time.
Subroutines in multiple packages within the same file are supported - but
you should note that this requires exporting
SelfLoader::AUTOLOAD
to every package which requires it. This
is done automatically by the SelfLoader when it first loads the subs into the
cache, but you should really specify it in the initialization before the
__DATA__
by putting a
use
SelfLoader
statement in each package.
Fully qualified subroutine names are also supported. For example:
__DATA__
sub foo::bar {23}
package baz;
sub dob {32}
will all be loaded correctly by the SelfLoader, and the SelfLoader will ensure
that the packages "foo" and "baz" correctly have the
SelfLoader::AUTOLOAD
method when the data after
__DATA__
is first parsed.
See the discussion of autoloading in
Chapter 5
.
Also see the AutoLoader module, a
utility that handles modules that have been into a collection of files for
autoloading.