Perrin Harkins wrote: [...]
Let's step back for a minute. I am late to this party, since I haven't been working on the mp2 code at all or even doing much with it. Here's what it looks like to me, and please correct me if I'm wrong:
Because of the way the C API is laid out, it made sense to put these methods into different modules that parallel things in the C API. However, there was still a desire to have all of these methods available through $r. The solution chosen was to have other modules define things in the Apache::RequestRec namespace. I think this is the wrong solution because it confuses people about what they are using and what needs to be loaded explicitly.
The other force at work here is the desire to not load things that are not needed because of memory concerns. Perl has a standard way of handling delayed loading, which is AUTOLOAD and the AutoLoader/autosplit technique. The concern with that is that $r is currently an instance of a class that is not always loaded, and that delayed loading defeats the memory efficiency of preloading.
Here is what I suggest:
- Make $r an instance of a new class, something like Apache::RequestHandle, or else keep it in RequestRec but always load RequestRec.
- Define an AUTOLOAD method in that class which can load other modules on demand when people call methods on $r.
- Provide import groups that preload the AUTOLOADed functions, similar to what Josh said but still allowing AUTOLOADing of anything not preloaded. This would be almost identical to the CGI.pm pre-compile stuff.
This would allow full backwards compatibility with the current API too, at least for everything called through $r.
Good thinking, Perrin. But you need to take it all the way through, because I'm afraid you need to look at the whole picture and not lock yourlself in the $r world.
Let's say we do what you propose (which makes a lot of sense to me) for $r and its method containers Apache::Request*, Apache::Log, etc.
perl -MApache2 -MModPerl::MethodLookup -e print_object Apache::RequestRec | grep Apache | wc -l
146
That covers 146 methods in about 10 modules. What about the other 250+ in 30+ modules?
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.
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?
perl -MApache2 -MModPerl::MethodLookup -e print_object Apache::Server | grep Apache | wc -l
31
That covers 31 more methods and I think 3 modules. 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?) Where do you install that AUTOLOAD on functions or modules which aren't $r or $s operators? In a $SIG{__DIE__} handler or overriding GLOBAL::CORE::die, or in UNIVERSAL::AUTOLOAD, which has a pack of its own troubles?
Thanks. __________________________________________________________________ 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]
