First you might wonder, why in the world will someone need to define an
inner subroutine? Well, for example to reduce some of Perl’s script startup
overhead you might decide to write a daemon that will compile the scripts
and modules only once, and cache the pre-compiled code in memory. When some
script is to be executed, you just tell the daemon the name of the script
to run and it will do the rest and do it much faster since compilation has
already taken place.
Seems like an easy task, and it is. The only problem is once the script is
compiled, how do you execute it? Or let’s put it the other way: after it
was executed for the first time and it stays compiled in the daemon’s
memory, how do you call it again? If you could get all developers to code
their scripts so each has a subroutine called run() that will
actually execute the code in the script then we’ve solved half the problem.
But how does the daemon know to refer to some specific script if they all
run in the main:: name space? One solution might be to ask the developers to declare a
package in each and every script, and for the package name to be derived
from the script name. However, since there is a chance that there will be
more than one script with the same name but residing in different
directories, then in order to prevent namespace collisions the directory
has to be a part of the package name too. And don’t forget that the script
may be moved from one directory to another, so you will have to make sure
that the package name is corrected every time the script gets moved.
But why enforce these strange rules on developers, when we can arrange for
our daemon to do this work? For every script that the daemon is about to
execute for the first time, the script should be wrapped inside the package
whose name is constructed from the mangled path to the script and a
subroutine called run(). For example if the daemon is about to
execute the script /tmp/hello.pl:
cache::