Am Samstag, 17. Januar 2004 20:09 schrieb Geoffrey Young: > > 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
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); If it turns out that it is worth to have a $r->is_initial_req() it must be defined in Apache::RequestRec. This way it is also possible to change this method in subclasses of Apache::RequestRec. > 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. This in not bloat it is part of my object! In my oppinion the function must be part of both Apache::RequestRec and Apache::RequestUtil. Maybe the Apache::RequestRec is the wrong name since a perl user dont want a mirror of the C API or structs he want objects that do things easy WITH whatever API. > > 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] -- Boris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]