> Neither is loading a bunch of modules that you don't actually access > directly,
well... > or using a program to look up where the docs for the method > you're calling are. There are basic expectations that programmers have > about when they need to load things and where they can find docs, and > these are being foiled right now. I agree totally with that. yet another thing that I thought sucked :) > Incidentally, is there a decent tutorial for the apache 2 C API > anywhere? The stuff I found on httpd.apache.org was pretty thin. not that I know about. ryan bloom's book I think is the closest, but I've not read it. > I'm not complaining about $r, but rather about the inconsistency between > calling the methods on Apache::RequestRec but loading them and reading > their docs in other classes.. the docs are definitely an issue. > >> granted, $r is not a typical Perl object, but it can't be >> > > I don't understand why. well, for one it's singleton-esque, which makes it kinda unique. > >> and you can't subclass $r's underlying class the same >> way you can normal Perl objects. >> >> > > Why not? Because of the stuff I'm complaining about? I don't think so. beneath it all each object method needs access to the c request_rec, and $r needs to keep its singleton nature. which doesn't mean you can't subclass it, you just need to use the bless { r => $r}, $class syntax. that's what I meant by "the same way you can normal Perl objects" - subclasses have a non-standard syntax. > > I always thought it was pointlessly dangerous to subclass $r in mp1, but > I know people did it with alarming frequency. I've never seen it be dangerous, though I suspect it could be abused. but it's also amazingly powerful > >> there isn't much >> different here than there was in mp1 wrt classes that add methods to $r, >> just a bit more of it. >> >> > > No, there's tons more of it, and unlike mp1 it is for methods that > people actually will need to use. The stuff in mp1 was pretty obscure. :) as for your earlier suggestions, I was waiting for stas to comment on them. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]