perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Date Wed, 07 May 2003 00:31:35 GMT
Josh Chamas wrote:
> Stas Bekman wrote:
>> Another minor optimization would be to use:
>> use constant MODPERL2 => ...; instead of $ModPerl2
>> this will save a few if() run-time checks.
> Thanks for the tip.  The $ModPerl2 in this case is calculated
> at module load time, so I think the effect is the same, its just
> not a constant.

The effect is very different, that's the whole point of using constants. By 
using a constant the parser will optimize the code and throw away the branches 
that won't be executed.

>> Bad programmer, no cookie ;)
>> Seriously, please do not do that. Currently there are 38 Classes and 
>> more will be added. You hardly need 10 or so classes. and if users 
>> want some functionality in their code, they should be responsible for 
>> loading it. Now if I use Apache::ASP you force the loading of all 
>> modules on me, even if I don't want them and Apache::ASP doesn't use 
>> even half of them. 
> I don't really use that much of the Apache API, just part of what is
> exposed with the basic mod_perl 1 API.  So why then would I have to 
> explicitly
> load 9 separate modules?  I was really astonished when I had to load
> Apache::Log for using log_error(), just as an example.
> So how about some generic loader that loads a partial "CORE" set of
> modules, especially to help with porting 

Apache::compat does that already, since you are talking about helping with 
porting. Just copy and paste a list of modules it loads, and move on.

> like Apache::Common or some such,
> that just exposes what developers are used to programming with from mp1 
> days,
> but without the full  &ModPerl::MethodLookup::preload_all_modules();
> So an Apache::Common, might just be:
> package Apache::Common;
> use Apache::RequestRec ();
> use Apache::RequestUtil ();
> use Apache::RequestIO ();
> use Apache::Response ();
> use APR::Table ();
> use APR::Pool ();
> use Apache::Connection ();
> use Apache::Server ();
> use Apache::Log ();
> # maybe some some others that those on the dev list would want to include?
> 1;

I believe, very quickly this common thing will grow, as different people have 
different needs and it's going to be hard to find a golden middle. For example 
if I don't use HTTP handlers, but use mp2 to write protocol modules, my common 
list wouldn't include any of the Apache::Request* modules.

Very quickly you will find all the modules that Apache::ASP needs to load and 
you will move on to deal with other problems. It's not like you say *argh* 
every few minutes for the next few years to come, because every time some 
module wasn't loaded.

mp2 is not a self contained thing, doing just a few things, as with mp1. Think 
of mp2 as a much richer toolkit, that can do many things that weren't possible 
with mp1. Therefore there is no longer one-fit-all solution. You choose what 
modules you want to use and you use them.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message