- The __DATA__ token
- SelfLoader autoloading
- Autoloading and package lexicals
- SelfLoader and AutoLoader
- __DATA__, __END__, and the FOOBAR::DATA filehandle.
- Classes and inherited methods.
- Multiple packages and fully qualified subroutine names
- COPYRIGHT AND LICENSE
SelfLoader - load functions only on demand
The __DATA__ token
__DATA__ token tells the perl compiler that the perl code
for compilation is finished. Everything after the
is available for reading via the filehandle FOOBAR::DATA,
where FOOBAR is the name of the current package when the
token is reached. This works just the same as
__END__ does in
package 'main', but for other modules data after
__END__ is not
automatically retrievable, whereas data after
__DATA__ token is not recognized in versions of perl prior to
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. This also applies to
__END__ and main, i.e. if
the 'main' program has an
__END__, but a module 'require'd (_not_ 'use'd)
by that program has a 'package main;' declaration followed by an '
filehandle is set to access the data after the
in the module, _not_ the data after the
__END__ token in the 'main'
program, since the compiler encounters the 'require'd file later.
The SelfLoader works by the user placing the
token after perl code which needs to be compiled and
run at 'require' time, but before subroutine declarations
that can be loaded in later - usually because they may never
The SelfLoader will read from the FOOBAR::DATA filehandle to
load in the data after
__DATA__, and load in any subroutine
when it is called. The costs are the one-time parsing of the
__DATA__, and a load delay for the _first_
call of any autoloaded function. The benefits (hopefully)
are a speeded up compilation phase, with no need to load
functions which are never used.
The SelfLoader will stop reading from
it encounters the
__END__ token - just as you would expect.
__END__ token is present, and is followed by the
token DATA, then the SelfLoader leaves the FOOBAR::DATA
filehandle open on the line after that token.
The SelfLoader exports the
AUTOLOAD subroutine to the
package using the SelfLoader, and this loads the called
subroutine when it is first called.
There is no advantage to putting subroutines which will _always_
be called after the
Autoloading and package lexicals
A 'my $pack_lexical' statement makes the variable $pack_lexical
local _only_ to the file up to the
__DATA__ token. Subroutines
declared elsewhere _cannot_ see these types of variables,
just as if you declared subroutines in the package but in another
file, they cannot see these variables.
So specifically, autoloaded functions cannot see package
lexicals (this applies to both the SelfLoader and the Autoloader).
pragma provides an alternative to defining package-level
globals that will be visible to autoloaded routines. See the documentation
on vars in the pragma section of perlmod.
SelfLoader and AutoLoader
The SelfLoader can replace the AutoLoader - just change 'use AutoLoader'
to 'use SelfLoader' (though note that the SelfLoader exports
the AUTOLOAD function - but if you have your own AUTOLOAD and
are using the AutoLoader too, you probably know what you're doing),
__END__ token to
__DATA__. You will need perl version 5.001m
or later to use this (version 5.001 with all patches up to patch m).
There is no need to inherit from the SelfLoader.
The SelfLoader works similarly to the AutoLoader, but picks up the
subs from after the
__DATA__ instead of in the 'lib/auto' directory.
There is a maintenance gain in not needing to run AutoSplit on the module
at installation, and a runtime gain in not needing to keep opening and
closing files to load subs. There is a runtime loss in needing
to parse the code after the
__DATA__. Details of the AutoLoader and
another view of these distinctions can be found in that module's
__DATA__, __END__, and the FOOBAR::DATA filehandle.
This section is only relevant if you want to use
together with the SelfLoader.
Data after the
__DATA__ token in a module is read using the
__END__ can still be used to denote the end
__DATA__ section if followed by the token DATA - this is supported
by the SelfLoader. The
filehandle is left open if an
__END__ followed by a DATA is found, with the filehandle positioned at
the start of the line after the
__END__ token. If no
__END__ token is
present, or an
__END__ token with no DATA token on the same line, then
the filehandle is closed.
The SelfLoader reads from wherever the current
position of the
filehandle is, until the
__END__. This means that if you want to use
that filehandle (and ONLY if you want to), you should either
1. Put all your subroutine declarations immediately after
__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
reads first by calling 'SelfLoader->load_stubs();', or by using a
function which is selfloaded;
2. You should read the
filehandle first, leaving
the handle open and positioned at the first line of subroutine
You could conceivably do both.
Classes and inherited methods.
For modules which are not classes, this section is not relevant. This section is only relevant if you have methods which could be inherited.
A subroutine stub (or forward declaration) looks like
- sub stub;
i.e. it is a subroutine declaration without the body of the subroutine. For modules which are not classes, there is no real need for stubs as far as autoloading is concerned.
For modules which 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
module is available. However this does require the extra step of ensuring
that the stubs are in the module. If this is done I strongly recommend
that this is done BEFORE releasing the module - it should NOT be done
at install time in general.
Multiple packages and fully qualified subroutine names
Subroutines in multiple packages within the same file are supported - but you
should note that this requires exporting the
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,
will all be loaded correctly by the SelfLoader, and the SelfLoader
will ensure that the packages 'foo' and 'baz' correctly have the
AUTOLOAD method when the data after
__DATA__ is first
is maintained by the perl5-porters. Please direct
any questions to the canonical mailing list. Anything that
is applicable to the CPAN release can be sent to its maintainer,
Author and Maintainer: The Perl5-Porters <firstname.lastname@example.org>
Maintainer of the CPAN release: Steffen Mueller <email@example.com>
COPYRIGHT AND LICENSE
This package has been part of the perl core since the first release of perl5. It has been released separately to CPAN so older installations can benefit from bug fixes.
This package has the same copyright and license as the perl core:
- Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999,
- 2000, 2001, 2002, 2003, 2004, 2005, 2006 by Larry Wall and others
- All rights reserved.
- This program is free software; you can redistribute it and/or modify
- it under the terms of either:
- a) the GNU General Public License as published by the Free
- Software Foundation; either version 1, or (at your option) any
- later version, or
- b) the "Artistic License" which comes with this Kit.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See either
- the GNU General Public License or the Artistic License for more details.
- You should have received a copy of the Artistic License with this
- Kit, in the file named "Artistic". If not, I'll be glad to provide one.
- You should also have received a copy of the GNU General Public License
- along with this program in the file named "Copying". If not, write to the
- Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
- MA 02110-1301, USA or visit their web page on the internet at
- For those of you that choose to use the GNU General Public License,
- my interpretation of the GNU General Public License is that no Perl
- script falls under the terms of the GPL unless you explicitly put
- said script under the terms of the GPL yourself. Furthermore, any
- object code linked with perl does not automatically fall under the
- terms of the GPL, provided such object code only adds definitions
- of subroutines and variables, and does not otherwise impair the
- resulting interpreter from executing any standard Perl script. I
- consider linking in C subroutines in this manner to be the moral
- equivalent of defining subroutines in the Perl language itself. You
- may sell such an object file as proprietary provided that you provide
- or offer to provide the Perl source, as specified by the GNU General
- Public License. (This is merely an alternate way of specifying input
- to the program.) You may also sell a binary produced by the dumping of
- a running Perl script that belongs to you, provided that you provide or
- offer to provide the Perl source as specified by the GPL. (The
- fact that a Perl interpreter and your code are in the same binary file
- is, in this case, a form of mere aggregation.) This is my interpretation
- of the GPL. If you still have concerns or difficulties understanding
- my intent, feel free to contact me. Of course, the Artistic License
- spells all this out for your protection, so you may prefer to use that.