but Apache::RequestUtil::is_initial_req expect an object blessed into Apache::RequestRec. So:
$r->is_initial_req();
is fine.
No, it's not. $r is not an instance of Apache::RequestUtil, so calling methods on it that are defined in Apache::RequestUtil makes no sense. This is what I'm objecting to. If Apache::RequestUtil were hidden and didn't have to be explicitly loaded by the user, I would not have a problem with this.
Huh? Isn't $r an instance of Apache::RequestRec? If not, what is it?
It is. But you are confusing the name of the class 'Apache::RequestRec' with a module Apache/RequestRec.(pm|so). You can perfectly use $r w/o ever loading the module Apache/RequestRec.(pm|so).
Are you saying that $r is blessed into a class that may or not be loaded? I think that's not a good idea. $r should always be an instance of a real class. If you don't want to force Apache::RequestRec to be loaded, then make $r an instance of something else that will always be loaded, like maybe a tiny class that exists just to autoload the methods you call on it.
Here is an example:
package MyLog; use Apache::Log; use Apache::Const -compile => 'OK'; sub handler { my $r = shift; $r->log_error("whatever"); return Apache::OK; }
That looks totally wrong to me, unless $r is an instance of Apache::Log, which I know it isn't in this case.
Where would you install AUTOLOAD? In which class?
In Apache::RequestRec, or whatever (loaded) class $r is going to be.
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.
- Perrin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
