SelfLoader(3perl)

SelfLoader(3perl) — straight out of the Perl Programmers Reference Guide, now with ✨main character energy✨

---

🌸 NAME 🌸

SelfLoader — loads functions only when you actually need them, on demand. 💅

✨ SYNOPSIS ✨

package FOOBAR;
use SelfLoader;

... (initializing code)

__DATA__
sub {....

🦋 DESCRIPTION 🦋

Okay so basically, this module tells everyone who uses it that the functions in the FOOBAR package are gonna be autoloaded from after the __DATA__ token. Also go peek at "Autoloading" in perlsub if you want the lore. ✨

🎀 The __DATA__ token 🎀

The __DATA__ token is literally the compiler's way of saying "okay we're done here bestie". Everything after the __DATA__ token can be read via the filehandle FOOBAR::DATA, where FOOBAR is whatever package is current when the compiler hits the __DATA__ token. It's the same vibe as __END__ in package 'main' — except for other modules, data after __END__ is not automatically retrievable, whereas data after __DATA__ is. And heads up: __DATA__ is not recognized in versions of perl prior to 5.001m. 💀

Also note that you can have __DATA__ tokens in the same package across multiple files, and it's the last __DATA__ token in a given package that the compiler encounters which is the one accessible by the filehandle. Same energy applies to __END__ and main: like, 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 "__DATA__", then the DATA filehandle is set to access the data after the __DATA__ in the module, not the data after the __END__ token in the 'main' program — because the compiler encounters the 'require'd file later. Periodt. 👑

🌈 SelfLoader autoloading 🌈

So how's it work? The user places the __DATA__ token after the perl code that needs to be compiled and run at 'require' time, but before the subroutine declarations that can be loaded in later — usually because they may never get called at all. 🤷♀️

Then SelfLoader reads from the FOOBAR::DATA filehandle to load in the data after __DATA__, and loads in any subroutine whenever it's called. The costs are the one-time parsing of the data after __DATA__, plus a load delay for the first call of any autoloaded function. The benefits (hopefully 🙏) are a sped up compilation phase, with no need to load functions which are never used.

SelfLoader will stop reading from __DATA__ if it encounters the __END__ token — just as you'd expect, no cap. And if the __END__ token is present and is followed by the token DATA, then SelfLoader leaves the FOOBAR::DATA filehandle open on the line after that token. 🫶

SelfLoader exports the AUTOLOAD subroutine to the package that's using the SelfLoader, and that is what loads the called subroutine when it's first called.

And listen — there is no advantage to putting subroutines which will always be called after the __DATA__ token. Don't do it. Save yourself. 💅

🍓 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 — exactly like how if you declared subroutines in the package but in another file, they can't see these variables either. It's giving closed curtain. 🚪

So specifically, autoloaded functions cannot see package lexicals (this applies to both the SelfLoader and the Autoloader). The vars pragma gives you an alternative to defining package-level globals that will be visible to autoloaded routines. The documentation on vars lives in the pragma section of perlmod. ✨

💜 SelfLoader and AutoLoader 💜

SelfLoader can replace the AutoLoader — you literally just change 'use AutoLoader' to 'use SelfLoader' (though note that SelfLoader exports the AUTOLOAD function — but if you have your own AUTOLOAD and you're using the AutoLoader too, you probably know what you're doing 😌), and change the __END__ token to __DATA__. You'll need perl version 5.001m or later for this (version 5.001 with all patches up to patch m).

There is no need to inherit from the SelfLoader. None. Zero. 🙅♀️

SelfLoader works similarly to the AutoLoader, but it picks up the subs from after the __DATA__ instead of in the lib/auto directory. There's 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 documentation. 📚

🧚 __DATA__, __END__, and the FOOBAR::DATA filehandle 🧚

This section is only relevant if you want to use the FOOBAR::DATA together with the SelfLoader. Otherwise scroll on, bestie.

Data after the __DATA__ token in a module is read using the FOOBAR::DATA filehandle. __END__ can still be used to denote the end of the __DATA__ section if followed by the token DATA — this is supported by the SelfLoader. The FOOBAR::DATA 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. But if no __END__ token is present, or there's an __END__ token with no DATA token on the same line, then the filehandle is closed. 🚪💀

SelfLoader reads from wherever the current position of the FOOBAR::DATA filehandle is, until the EOF or __END__. Which means if you want to use that filehandle (and ONLY if you want to), you should either:

1. 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 reads first, by calling 'SelfLoader->load_stubs();', or by using a function which is selfloaded;

or

2. You should read the FOOBAR::DATA filehandle first, leaving the handle open and positioned at the first line of subroutine declarations.

You could conceivably do both. Both is an option, king behavior. 💅

👑 Classes and inherited methods 👑

For modules which are not classes, this section is not relevant — skip it, no shade. This section only matters if you have methods which could be inherited.

A subroutine stub (or forward declaration) looks like:

sub stub;

i.e. it's a subroutine declaration without the body of the subroutine. For modules which are not classes, there's 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. Easy.

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 this is done, the author strongly recommends doing it 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 heads up, this requires exporting the SelfLoader::AUTOLOAD to every package which requires it. The SelfLoader does this automatically 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. Just do it. 🎀

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. Slay. 🔥

🌸 AUTHOR 🌸

"SelfLoader" 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, though.

Author and Maintainer: The Perl5-Porters <perl5-porters@perl.org>

Maintainer of the CPAN release: Steffen Mueller <smueller@cpan.org>

💖 COPYRIGHT AND LICENSE 💖

Okay bestie, legal era. Don't scroll, this one actually matters 🫶

This package has been part of the perl core since the very first release of perl5, like day one iconic. It also got released separately to CPAN so older installations can benefit from bug fixes — yes, they're looking out for the vintage setups too, we love that. 👑

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.

All rights reserved, periodt. Moving on.

This program is free software; you can redistribute it and/or modify it under the terms of either:

1. a) the GNU General Public License as published by the Free Software Foundation; either version 1, or (at your option) any later version, or
2. b) the "Artistic License" which comes with this Kit.

So like, pick your fighter. Either one is valid, no need to do both. 🌈

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. (That's the "no promises, bestie" clause, keep it in mind fr fr 😭)

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, see <https://www.gnu.org/licenses/>.

---

✨ The Larry Wall GPL Interpretation Corner ✨

Okay so this next part is specifically for those of you that choose to use the GNU General Public License. Larry's own ✨interpretation✨, and honestly? It slaps. Here's the whole vibe:

• 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. Extremely reasonable of him ngl.

Of course, the Artistic License spells all this out for your protection, so you may prefer to use that. 💅

---

And that's a wrap on SelfLoader(3perl) gorgeous!! 🦋 From perl v5.44.0, dated 2026-10-17. Go forth and lazily load your subroutines, bestie — you ate 💖🌸