perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: a new stacked handlers paradigm
Date Wed, 04 Jun 2003 02:17:58 GMT
Geoffrey Young wrote:
> 
>> I prefer to extend modperl_handler_lookup_handlers to pick up this 
>> information from autogenerated code, same as it's done with desc. 
> 
> 
> ok, so you want another field added in addition to the desc.  how should 
> this be passed from modperl_handler_lookup_handlers, by reference as 
> with desc?
> 
> then you want modperl_hooks.c to have a series of parallels for 
> MP_modperl_handler_desc_per_dir for setting the run type, and a separate 
> function to parallel set_desc?

Something like that (again just an idea). Perhaps we should really create a 
struct:

typedef enum {
     VOID,
     RUN_FIRST,
     RUN_ALL
} modperl_hook_run_mode_e

struct modperl_hook_t {
     const char *desc;
     modperl_hook_run_mode_e run_mode;
};

and now we can kill all the modperl_handler_desc_ functions and just return 
this struct from modperl_hooks.c. Later on we might fold in more information. 
Do you think anything else should be added there?

Or is it considered a bad practice to create a struct for a static data that 
never changes?

>> 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).
> 
> 
> ok, I'll hold off on another patch until after we resolve the VOID 
> issue, then I'll try it  from modperl_handler_lookup_handlers instead 
> and see how it goes.

Cool


__________________________________________________________________
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


Mime
View raw message