> For the record, I agree with Boris on this. Users should never be > required to use methods defined in namespaces of modules that they did > not explicitly load, and modules should not define things in other > namespaces (like the Apache:: stuff that started this thread).
well, there are a few reasons for all of this. granted, it doesn't really make sense before you, well, understand it, but I like it :) so, here's my view on the whole thing... take Apache::RequestRec. it implements methods that provde access to the apache request_rec structure. so, load it and you get access to things like $r->uri() and $r->notes(), which are stored as the uri and notes slots in the C request_rec. now, take a method like is_initial_req(), which represents access to ap_is_initial_req. the call only makes sense at request-time, and the Apache API requires a request_rec structure. but it doesn't make sense to define it in Apache::RequestRec, since it does not access a property of the request_rec structure. so, 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). basically, in Perl we get an API that makes sense: operations that require a request_rec in C are called from $r in Perl. 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. 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. I suspect (but don't know for certain) that this was an implementation style that popped up later in mp1's lifecycle, and that Doug decided it was the way mp2 ought to work. personally, I'm really in favor of the way things look now (save the things that started this thread). not only do they represent a cleaner Perl API layer (my favorite part) but they allow applications to keep unnecessary symbols out of their code. granted, it takes a while to get used to, but I like it and I hope it will grow on everyone as it has on me. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
