httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [multi-env] perl glue implications
Date Thu, 03 Feb 2005 04:06:11 GMT
Joe Schaefer wrote:
> Joe Schaefer <joe+gmane@sunstarsys.com> writes:
> 
> 
>>Stas Bekman <stas@stason.org> writes:
>>
>>
>>>Joe Schaefer wrote:
>>
>>[...]
>>
>>
>>>>What I think this will bubble up into, from the perl glue standpoint,
>>>>is a new barebones APR:: heirarchy that might work like so
>>>>
>>>>  my $req = APR::Request->new($r, MODULE => "Apache2"); # apreq_handle_t
>>>
>>>which should probably be abstracted into:
>>>
>>>   my $req = Apache2::Request->new($r);
>>>
>>>with Apache2::Request being a subclass (or Apache::Request, whatever
>>>it is). 
>>
>>Actually I'm thinking of APR::Request as being an analog of
>>DBI.pm, and the MODULE attribute determines the helper (DBD-like) 
>>class.  Here an entire driver class might not even be 
>>necessary though, since apreq will only need a single 
>>C function (an apreq_handle_t* constructor) from the 
>>helper module.
> 
> 
> Hmm, rereading what's actually written above, maybe thinking
> of APR::Request as a class with a "virtual" constructor
> (ie no APR::Request::new() sub) is a better idea than
> what I first proposed.
> 
> Is that more or less what you have in mind Stas?

Either way works for me.

All I was suggesting is to allow the users to type less. So this of course 
can be done later on and doesn't impede the APR::Request design.

-- 
__________________________________________________________________
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

Mime
View raw message