httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <>
Subject Re: Subclassing Apache::Request
Date Tue, 29 Apr 2003 15:36:54 GMT
Geoffrey Young wrote:

> > The other idea that came back from the mod_perl mailing list was to
> > aggregate:
> >
> >     sub new {
> >         my($class, @args) = @_;
> >         return bless { _r => Apache::Request->new(@args) }, $class;
> >     }
> >
> > but that would then require an AUTOLOAD() method or similar
> > to delegate
> > Apache::Request methods to the contained Apache::Request
> > object; this is
> > even more annoying than my "re-blessing" suggestion above.
> this happens automagically. 

Ah.  I utterly hadn't appreciated the automagic dimension here.

I simply didn't accept that a sub-class whose instances _contain_ 
Apache::Request objects (as opposed to being Apache::Request objects 
re-blessed and maybe even extended) could possibly inherit 
Apache::Request methods.

I've had a closer look now that I realise there is magic involved, and 
it all makes sense!

It all stems from the T_APROBJ typemap and the sv_2apreq() function that 
it uses doesn't it?  Joe mentioned that typemap, but I missed the 
significance of that remark.

If I understand it correctly, sv_2apreq() uses r_key_sv() to "find" an 
Apache::Request object _contained in_ the invocant object, if 
necessary... hence also Joe's comment about 'r' and '_r' being 
"documented to be safe for this purpose", the significance of which I 
also missed :-(

BTW, where is the documentation that Joe referred to?  I've read through 
the Apache::Request and libapreq manpages, as well as the Apache and 
various mod_perl manpages, and never saw any comment about this use of 
'r' and '_r', or the automagic sub-classing behaviour generally.  It's 
fair enough having to buy books to find more detail and examples of 
these things in action, but I wouldn't expect to have to refer to books 
just to find that such features even exist!  Perhaps a documentation 
patch would be in order?

Anyway, thanks for your patience in explaining this to me.



View raw message