Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3EDC532A.3000200@stason.org>
Date: Tue, 03 Jun 2003 17:50:02 +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: Geoffrey Young <geoff@modperlcookbook.org>
Cc: dev@perl.apache.org
Subject: Re: a new stacked handlers paradigm
References: <3ED79AFE.4000900@modperlcookbook.org>
 <3EDA94E5.3010803@stason.org> <3EDBB34F.1020404@modperlcookbook.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Geoffrey Young wrote:
> ok, I took another stab at it.  this one is much simpler - it only touches
> modperl_callback.c.  I didn't see the reason for an enum, and there's no 
> point in moving the logic to lookup_handlers(), since there's nothing 
> that lookup_handlers() knows that modperl_callback() didn't tell it.  
> I'm not too sure about whether that switch statement is the way to go, 
> but it's another iteration for everyone to discuss at least.  oh, and 
> the test is more self contained now, too :)

I prefer to extend modperl_handler_lookup_handlers to pick up this information 
from autogenerated code, same as it's done with desc. Why clutter the 
maintenance and run-time overhead? It's correct that you don't need to call 
lookup_handlers() and you have all the info, but you still need to add a 
switch and ugly sets of ifs. Since you are already calling 
modperl_handler_lookup_handlers why not pick the information from there and 
avoid any branching at all?

See the other thread I've spawned from this one. We probably want to handle 
VOID types differently as well, so it's a perfect addition to the work you do. 
  in that case the run_all var must be a tri-state (that's why I've suggested 
enums).

Also the test(s) need indentation fixing.

__________________________________________________________________
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