Devel:...tubber(3perl)

✨ NAME ✨

okay so bestie, meet Devel::SelfStubber (it's a 3perl kinda situation, from the Perl Programmers Reference Guide) — it generates stubs for a SelfLoading module 💅

---

✨ SYNOPSIS ✨

if you just want the stubs and nothing else, it's giving:

use Devel::SelfStubber;
Devel::SelfStubber->stub('MODULENAME','MY_LIB_DIR');

or, if you want the whole entire module with the stubs slotted in correctly, do this:

use Devel::SelfStubber;
$Devel::SelfStubber::JUST_STUBS=0;
Devel::SelfStubber->stub('MODULENAME','MY_LIB_DIR');

okay important thing, no cap: MODULENAME is the Perl module name, like Devel::SelfStubber — NOT 'Devel/SelfStubber' and NOT 'Devel/SelfStubber.pm'. don't do that. that's not the vibe. 🙈

and MY_LIB_DIR defaults to . if you don't hand it one. periodt. ✨

---

✨ DESCRIPTION ✨

so what does it actually do? Devel::SelfStubber prints the stubs you need to put in the module before the __DATA__ token — or, if you're feeling extra, you can make it print the entire module with the stubs correctly placed. why do we care? because the stubs make sure that if a method gets called, it will get loaded. 🫶

and like, specifically? they're needed for inherited autoloaded methods. that's the whole thing. that's the assignment.

the best way to explain this is with an example, so buckle up:

assume four classes: A, B, C & D.

A is the root class, B is a subclass of A, C is a subclass of B, and D is another subclass of A.

                               A
                              / \
                             B   D
                            /
                           C

okay now here's the plot 💀 If D calls an autoloaded method 'foo' which is defined in class A, then the method is loaded into class A, then executed. fine, whatever. but then if C calls method 'foo', and that method was reimplemented in class B but set to be autoloaded... the lookup mechanism never gets to the AUTOLOAD mechanism in B, because it first finds the method already loaded in A, and so erroneously uses that. 😭 it's giving wrong answer. it's giving bug.

but!! if the method foo had been stubbed in B, then the lookup mechanism would have found the stub, and correctly loaded and used the sub from B. slay. 🎀

so: for classes and subclasses to have inheritance correctly work with autoloading, you need to ensure stubs are loaded. no stubs, no slay.

the SelfLoader can load stubs automatically at module initialization with the statement 'SelfLoader->load_stubs()'; — cute — but you may wish to avoid having the stub loading overhead associated with your initialization. (though ngl, note that the SelfLoader::load_stubs method will be called sooner or later — at latest when the first sub is being autoloaded.) in that case, you can put the sub stubs before the __DATA__ token. you could do this manually, but this module lets you automatically generate the stubs. main character energy honestly. 👑

by default it just prints the stubs, but you can set the global $Devel::SelfStubber::JUST_STUBS to 0 and it will print out the entire module with the stubs positioned correctly. 🌈

and at the very least, this is useful to see what the SelfLoader thinks are stubs — because, in order to ensure future versions of the SelfStubber remain in step with the SelfLoader, the SelfStubber actually uses the SelfLoader to determine which stubs are needed. yes bestie, it checks its own work. iconic behaviour fr fr. ⭐

---

💖 tiny reminder: MODULENAME is the Perl module name like Devel::SelfStubber, not a path like 'Devel/SelfStubber.pm'. and MY_LIB_DIR defaults to .. iykyk. 🦋

---

and that's the whole page, bestie!! this one's perl v5.44.0 and it's dated 2026-10-17, from the Devel:...tubber(3perl) era 💜 thanks for reading all the way to the bottom, you ate that. 🍓✨