perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [rfc] APR::Table & polymorphic values
Date Wed, 04 Jun 2003 18:38:34 GMT
Stas Bekman <stas@stason.org> writes:

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

For APR::Tables, that's right- the copy/merge callbacks (which I'm 
confident apr will adopt) will take care to add some appropriate
metadata during STORE.

> What if you use mpxs_apr_table_do to fixup the elements on the first
> FETCH? Would that be a bad approach? 

Not sure what you have in mind.

> The problem is that I still don't understand what do you need that
> meta data for and how is it used.

  1) the perl-glue for apreq will finally be able to handle embedded 
     nul characters,
  2) we can duplicate CGI.pm's overloading of params, since file-uploads
     are just params with a non-NULL bucket-brigade attached.
  3) we can do lots of cool stuff with cookie values, too.

Here's another idea that is safe, and should work for everyone:
just add a magic pointer to the original (char *) and keep using
newSVpv():

  
  MP_INLINE static SV *mpxs_apr_table_str_2sv(pTHX_ const char *str)
  {
        SV *sv = newSVpv(str, 0);
        sv_magic(sv, Nullsv, PERL_MAGIC_ext, str, 0);
        return sv_2mortal(sv);
  }

This way Apache::Request::Table can get at the original string
via mg->mg_ptr, so it just needs to maintain an sv_fixup XSUB.

If this looks ok, I'll try to conjure up a patch :-)
-- 
Joe Schaefer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message