Loading subroutines ad-hoc: extension to load.pm

After feedback from the Amsterdam Perl Mongers and some other people, 
I'm considering some additions to the "load" pragma that I developed 
and put on CPAN a few years back.

So what does "load" do?  Well, it basically (optionally) delays 
loading of subroutines until they're actually called (useful inside 
cronjobs).  *Or* it loads all subroutines of a module at compile time 
(useful in an Apache mod_perl environment).  And all of that with 
minimal changes to the source code.

So what changes would you need to make to the source code?  Well, 
basically there are 2 changes you need to do:

1. add "use load;" near the top of the file
2. put all subroutines that need to be loaded "on demand" after an 
__END__ marker

What the "use load" does, is that it scans the source file from which 
it is being called between the first __END__ and the second __END__ 
or __DATA__ or end of file.  In a mod_perl environment it will 
immediately "eval" the subroutines.  If not in a mod_perl 
environment, it will create a directory of file offsets / lengths of 
the subroutines it finds, which can be used later by an AUTOLOAD 
handler to read from the source file and "eval" the subroutine when 
it is actually being called.

So what are the disadvantages to this approach?  Well, the most 
noticeable one is the lack of support of file lexicals.  Since each 
subroutine is potentially compiled seperately, it cannot see file 
lexicals (since they can only be "seen" during compilation).

The second disadvantage to this approach is the fact that it in 
mod_perl, it is an all or nothing approach: either all subroutines 
are loaded on demand, or all are loaded at compile time.  I want to 
achieve a greater granularity.  For any given module, only load these 
X subroutines on the basic application server, load these Y 
subroutines on the XML server, and load these Z subroutines on the 
administrative servers.  Where X, Y and Z may be supersets, subsets 
or intersections.


I was therefore thinking about adding the following generic 
functionality to "load.pm":


1. support for related subroutines, grouped in a block
By adding support for the simple source parser for lexical blocks, it 
would become possible to "share" lexicals between subroutines.  This 
is in fact no different from what some of us are already doing:

{
my $foo;

sub foo { $foo }
sub bar { $foo + $foo }
}

The source parser of "load.pm" would see this as one entity: whenever 
"foo" or "bar" would be called, the entire block would be evalled, 
causing "$foo" to be accessible by both "foo" and "bar".


2. support for "roles"
The concept of a "role" would be the conceptual context in which code 
is being compiled.  Taking the about X, Y and Z example, a module 
might contain code that should be accessible in all 3 contexts, but 
also code that should only be accessible (and compiled) in the Z 
context.

I am thinking of adding a "compile time" directive to the "load.pm" 
source scanner that would indicate in which "role" or "roles" the 
code should be visible.  Something like:

#roles: admin,app
sub foo { ... }

#roles: admin
sub bar { ... }
sub baz { ... }

A line that starts with "#roles:" would indicate the roles in which 
the following code should be visible.  In the above example, the 
subroutine "foo" would only be visible in the "app" and "admin" roles.

In a mod_perl environment, it would compile only those subroutines of 
that role.  Outside of a mod_perl environment, the AUTOLOAD handler 
would refuse to load any subroutines of which the role doesn't match.

The actual role for which code should be compiled, is set with an 
environment variable, e.g. $ENV{ROLE}.  Whenever code is encountered 
that is not supposed to be available for that ROLE, measures will be 
taken so that that code is not compiled (and execution errors will 
ensue if you still try to do that).


3. preventing typo's in roles
To prevent typo's in role specifications, the first line with #roles: 
should contain all possible roles that any subroutine in this file 
could live in.  This would also serve as a visual cue as to which 
roles are supported for the developer.  So for the above X, Y and Z 
example, we'd probably have a line with:

  #roles: admin,app,xml

near the top of the file.


4. making other code conditional on role
A constant would be exported (e.g. by default ROLE) that would allow 
you to actually make conditions on the role:

   if ( ROLE eq 'app' ) {  # optimised away if ROLE ne 'app'
     print STDERR "compiled for 'app' role\n";
   }


5. propagate strict and warnings
Currently, any "use strict" and "use warnings" are not propagated to 
code actually being evalled.  Within the constraints of the simple 
source code parser, it will try to remember the last setting of 
"use/no strict" and "use/no warnings" seen.  Alternately, the 
import() routine of load.pm will allow specification of pragma's to 
be prefixed to each piece of code being evalled.  Something like:

   use load(
     use => 'warnings',
     use => 'strict',
   );

Perhaps that should even be the default setting.



I'm looking into this to scratch the itch of a client.  It was 
suggested to me to take this to a little bigger audience to see 
whether maybe such a beast already exists.  Or if it doesn't, to find 
out whether there would be any suggestions, remarks or other feedback 
that could be of interest.  ;-)






Liz

• Loading subroutines ad-hoc: extension to load.pm by Elizabeth Mattijsen
• Re: Loading subroutines ad-hoc: extension to load.pm by Shlomi Fish
• Re: Loading subroutines ad-hoc: extension to load.pm by Elizabeth Mattijsen