> How about making CGI.pm a subclass of $r? (optionally of course, by > dynamically changing @ISA), so instead of returning $q it'll return $r, > after re-blessing it.
Sounds interesting. What would be the advantage of that? Lincoln > > > The other issue is that it will only work with the OO form of CGI, which > > many people (including myself) don't use. > > You can still have an accessor function to set $r: > > use CGI; > CGI->r($r); > > > I would prefer a more transparent way to obtain the current request. Is > > there no low-overhead way of getting at this? > > Not, under threaded mpm. Since the code should work the same with threaded > and non-threaded mpm, it's a problem for any 2.0 code. The problem with > Apache->request is that it involves storing and retrieving data from the > TLS (thread local storage), which is slow. So while the functionality is > there, sites that are looking for high performance will want to pass $r, > rather than rely on Apache->request. > > Of course one can argue, that sites looking for high performance should use > Apache::Request (which is not quite there yet, for 2.0). So if this > argument is valid and you don't feel like changing the API, that's cool > too. May be in the future. > > __________________________________________________________________ > Stas Bekman JAm_pH ------> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com -- ======================================================================== Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY ========================================================================
