it's not the same. this call is:
Apache::RequestUtil::is_initial_req('Apache::RequestUtil', $r)
Right. That's what it should be, in my opinion. The $r object is not an instance of Apache::RequestUtil, so why would we want to call this method on $r?
Heh, I guess we have lost the track of who wants what. I started this thread exactly suggesting to eliminate this obscurity and not advocating for it.
I'm for removing the Apache:: stuff you talked about and also clearing up the confusion caused by having classes like Apache::RequestUtil apparently defining methods in Apache::RequestRec.
This seems to be what Boris is complaining about too, i.e. why does he have to load a whole bunch of separate modules if all of them just add things to $r?
that's what I've just suggested (Josh's idea). Though it's better be some other common name which will handle any groups and not Apache::RequestRec, because you don't necessarily need Apache::RequestRec at all.
Huh? Isn't $r an instance of Apache::RequestRec? If not, what is it?
I'm not a big fan of using the import() hooks like that. For one thing, CGI.pm doesn't die if you try to use something that you didn't pre-compile.
to be efficient it needs to do: goto &$AUTOLOAD; after loading Apache::RequestUtil, so it'll happen only once.
It could do that. Actually, within the context of these other classes that add stuff to $r, why can't they be AUTOLOADed? It doesn't seem like it would require a UNIVERSAL::AUTOLOAD, since all the methods are being called on one class.
What if you don't load 'Apache::RequestRec'? Who is going to load that wrapper?
You're confusing me again. Is $r not an instance of Apache::RequestRec?
What if people do load Apache::RequestUtil:
$r->is_initial_req($self)
now you've sub redefined in either of the two modules.
I'm not following. What is $self in this example?
- Perrin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
