Perrin Harkins wrote:

I understand that you will want to preload that module that knows how to AUTOLOAD the others on every handler that gets $r passed. Which works for me.


Good.  Do you think there should be a separate module for this, that
just acts a shell for $r and AUTOLOADs other things?  That would avoid
loading Apache::RequestRec unless it is needed.  Apache::RequestHandle
maybe?

You don't necessarily need a module for that. All you want to do is to install


sub Apache::RequestRec::AUTOLOAD, with a few lines of code.

it can live anywhere. We may have a special module (e.g. ModPerl::Controller or something like that) which can have hooks to install this kind of things. And will always loaded at the server startup and its hooked called from the C code.

If you want to do the same thing for $s, besides the child_init/child_exist hooks, none of the request hooks receives a server object. How do you know when to load that wrapper for $s?


How do we know if we should load the wrapper? We should always load it
if we're going to give anyone $s, and it can be such a small class
(Apache::ServerHandle?) that it won't add much to load it all the time.

That's exactly the problem. There are many cases where we don't pass $r explicitly but you can always get it via $r->server or $f->server, or Apache->server. So it's quite possible that the only solution is to always have this hook/wrapper preloaded.


BTW, inside a filter you can do $filter->r. Do you suggest that we change that accessor to install the wrapper too? That would be ineffective to do that on every call. So we end up with needing to preload the $r wrapper no matter what, just like $s.

Do you see what I meant by saying that you need to look beyond the mp1-like $r usage.

What about the other 200+ methods in about 30 modules? People will still need to figure out what to load to use these (e.g. Apache::URI's methods don't necessarily work with $r, so how do you know that you need to load that module?)


I think it's fine for people to explicitly load Apache::URI in order to
call methods like Apache::URI->foo(), but not for methods that are
called through $r, or $s, or any other object that the user gets passed.

But there are many other objects returned by mp2 API, beyong $r, $s and $c. what about them?


Where do you install that AUTOLOAD on functions or modules which aren't $r or $s operators?


I don't want to AUTOLOAD anything that isn't called through one of
those.

See, this is your "problem" - mp2 is much more than $r and $s. But you want to fix only those because you don't know about the others. We here try to have it right and homogenious for the whole API. So people who will want to use mp2 just to write filters won't say, why $r is easy but $f is not?


Think about it like this: $r and friends are the mod_perl API. Apache::RequestRec|IO|etc. are the implementation. If you look at
things like DBI, there is a precedent for doing it the way I'm
suggesting. DBI gives you a database handle, and deals with lots of
AUTOLOADed stuff behind the scenes. We advise people to put "use
DBD::Oracle" or whatever they are using in startup.pl as a tuning
measure. This would work the same way.

We have already agreed on that part I think. All I'm thinking about is the 'friends' part, which are a way too many, and some of them I don't even know about yet.


__________________________________________________________________
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


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to