Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3EB853E7.105@stason.org>
Date: Wed, 07 May 2003 10:31:35 +1000
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: Josh Chamas <josh@chamas.com>
Cc: dev@perl.apache.org
Subject: Re: [mp2] Making Apache::ASP optimized for mod_perl 2
References: <3EB753DB.70908@chamas.com> <3EB760F0.50709@stason.org>
 <3EB7CEC9.8070307@chamas.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org