perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [rfc] APR::Table & polymorphic values
Date Wed, 04 Jun 2003 02:52:34 GMT
Joe Schaefer wrote:
> Stas Bekman <stas@stason.org> writes:
> 
> 
> [...]
> 
> 
>>Still, once user tries to modify the data, what happens to meta-data?
>>When COW is performed, does it copy the whole thing or just whatever
>>was pointed by SvCUR?
> 
> 
> Doesn't matter.  The point is that if there's an Apache::Request::Table
> that subclasses APR::Table, it doesn't have to *reimplement everything*
> in APR::Table.  It can just fixup the return values before they are
> returned, like this:
> 
>   package Apache::Request::Table;
>   use base 'APR::Table';
> 
>   sub get {
>      if (wantarray) {
>         return map {fixup_sv($_)} &APR::Table::get;   
>     }
>     else {
>         return fixup_sv(scalar &APR::Table::get);
>     }
>   }
> 
> The only XSUB we'd need to maintain in the subclass is fixup_sv().
> But if APR::Table uses newSVpvn, Apache::Request::Table would need
> to *completely reimplent all* the APR::Table XSUBS.

So we really are concerned about FETCH, and never about STORE?

What if you use mpxs_apr_table_do to fixup the elements on the first FETCH? 
Would that be a bad approach? The problem is that I still don't understand 
what do you need that meta data for and how is it used.

__________________________________________________________________
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