in reply to Bootstrapping and cleaning after remote execution of method in framework consisting of multiple modules

It is possible to have many modules in one single file. To shorten startup time and delay compilation of methods until they are actually used, I'd do something like SelfLoader does.

I'd put all delayable code into the __DATA__ section, and provide each package with its start and end offsets into the __DATA__ section, in a hash table (initially written with enough whitespace for the values as placeholder for yet unknown offsets).

That way an AUTOLOAD subroutine would seek to that point, read the appropriate amount of bytes, eval them and goto the just compiled sub or method.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
  • Comment on Re: Bootstrapping and cleaning after remote execution of method in framework consisting of multiple modules

Replies are listed 'Best First'.
Re^2: Bootstrapping and cleaning after remote execution of method in framework consisting of multiple modules
by mman (Novice) on Aug 10, 2007 at 09:47 UTC
    Good solution for having all methods in one file, but we have tested another, less effective in perfomance, but clean-after-himself: we just 'use' all modules in framework (that is not so slow as we expected, about 0.2 sec). After 'use' each module is deleted, first of all starter.pl is runned by 'perl' and with '-d' option, when it's started it just deletes itself. So we got all necessary modules and no garbage in the directory.