it's definition is elsewhere, in Apache::RequestUtil, but Apache::RequestUtil defines Apache::RequestRec::is_initial_req(). the end result is that you can have the Perlish $r->is_initial_req() instead of the bulky Apache::RequestUtil::is_initial_req($r).
I would much prefer the longer one. It's more typing, but it also is much clearer. The current behavior just looks wrong to me.
Alternatively, you could be sneaky about it and load on demand, hiding this class completely from end users. Here's a simple exampe with no AUTOLOAD evil:
sub is_initial_req {
my $self = shift;
require Apache::RequestUtil;
return Apache::RequestUtil::is_initial_req($self);
}People who want to call the sub (shouldn't it actually be a method?) directly for speed still can.
why not just define is_initial_req() in Apache::RequestRec? well, for one it makes for a cleaner design: each of request_rec, server_rec, connection_rec have their own classes that provide access only to the slots in their specific record. but another good thing is that if your application only needs access to notes() and other request_rec attributes, then your code profile isn't bloated with symbols for is_initial_req() and other non-request_rec methods.
I think my approach above handles both of those. People who want to preload can look at what's in %INC after running their app.
while this may feel new, it's actually not: in mp1 you couldn't call $r->log->info without first loading Apache::Log, nor could you call $r->meets_conditions without first loading Apache::File.
But I didn't care then because those were obscure functions that I never used...
- Perrin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
