If the example function is_initial_req() does not use a record of request_rec and you think it makes no sense to define it in Apache::RequestRec then my conclusion is it makes also no sense to do a $r->is_initial_req() for the same reason and I'm happy to use Apache::RequestUtil::is_initial_req($r);
For what it's worth, Boris and I are saying exactly the same thing here: it makes no sense to require people to load class A in order to call a method on class B. What we have now is like a manual version of AutoLoader, but even worse since you have to go run a program in order to figure out which file you have to load.
In most languages, defining class A methods in class B would not even be allowed, and I kind of wish it wasn't allowed in Perl either so we wouldn't have to have this discussion.
in other words, everything is DWIM, save the need to load modules up front.
... but that is a huge problem. It also breaks the docs. If I am supposed to call is_initial_req() on $r, then the docs for that method have to be in the Apache::RequestRec POD, since $r is a RequestRec object.
mod_perl is access to the Apache C API in
Perl - the more they look the same (and the more people that understand
this) the better.
Obviously keeping these close is good for development of mod_perl, but no one is going to use mp2 if the API is confusing and difficult. Remember, most people programming mod_perl applications have never even looked at the C API, and I don't think there's anything wrong with that. Doug seemed to recognize that an easy Perl API is a necessity when he designed the simple filter stuff.
- Perrin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
