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 Tue, 03 Jun 2003 07:11:49 GMT
Joe Schaefer wrote:
> Stas Bekman <stas@stason.org> writes:
> 
> [...]
> 
> 
>>The question is whether this hit (e.g. magic retrieval) is wanted for
>>the general case. APR::Table is
> 
> 
> OK- how about using SvFAKE for the APR::Table return values instead?
> That way everybody wins- APR::Tables uses copy-on-write for the 
> returned SV's (which is faster than doing newSVpv), and apreq can 
> get the metadata back by interrogating those SV's (since they're 
> not copies, so SvPVX(sv) still points to the original data[1]).

I've checked that it's in 5.6.0 (The minimum that we need to support), though 
I'm not sure if it's working right. I haven't used it myself, but there is a 
lot of info in the thread starting from this post:

http://archive.develooper.com/perl5-porters@perl.org/msg96172.html

I haven't read the whole thread, but saw Tim Bunce suggesting later in this 
thread not to use SvFAKE:
http://archive.develooper.com/perl5-porters@perl.org/msg95102.html

May be all you need is to manipulate the pointers. So in normal case SVPV will 
point to the first char, in apreq case it'll point to the char the real data 
starts from. Am I shooting far off the target?

Besides that, once SvFAKE what happens if users try to modify it?

__________________________________________________________________
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