perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [rfc] APR::Table & polymorphic values
Date Wed, 04 Jun 2003 18:38:34 GMT
Stas Bekman <> writes:

> Joe Schaefer wrote:
> > Stas Bekman <> 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'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

  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:
For additional commands, e-mail:

View raw message