perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [rfc] APR::Table & polymorphic values
Date Mon, 02 Jun 2003 07:49:21 GMT
Joe Schaefer wrote:
> Stas Bekman <> writes:
>>Joe, what meta data are you talking about? Is it that new
>>things that you've merged into apr tables? 
> Yup.  

Is it committed already? I must have been looking at the old implementation then.

> Whenever someone does a table lookup in apreq-2, the 
> returned character string is always the last attribute of an 
> apreq_value_t struct, (which is also the last attribute of 
> either an apreq_param_t or an apreq_cookie_t struct).  
> For apreq-2, it would be nice if the c2perl conversion glue 
> was able to take this metadata into account.

>>Can you please point me to the source you are talking about?
> See httpd-apreq-2/src/apreq.h for the definition of apreq_value_t .
> All the parsers in apreq_parsers.c add param-> to the
> request body table, the cookie parser in apreq_cookie.c adds
> cookie-> to the jar->cookies table.

but you don't store apreq_value_t in the apr_table, you store only 
apreq_value_t->data. Do I miss some trick with data[1], as explained here: ?

>>Also how about using a sub-class of APR::Table which
>>overrides get/set to read/write this meta data? 
> Yes, that's a very good approach, and may be what
> we wind up needing for apreq-2.
>>It's probably more maitenance overhead, but will be faster
>>code-wise, no?
> Yes to the maintenance, since a lot of the APR::Table 
> XSUBs would need overriding. Dunno about the performance
> question- it's just a few extra pointer dereferences and 
> another C-function call, which may be faster than perl's 
> OO dispatch.

The question is whether this hit (e.g. magic retrieval) is wanted for the 
general case. APR::Table is

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

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

View raw message