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.
good thing Perl isn't most languages ;)
There are some legitimate uses for this feature (autoloading, code generation), but the key is to hide all this from users of the API.
I'll grant you that there is a bit
of an initial learning curve wrt the module loading that at first feels
quite painful (remember my NYC talk started with how all this sucks :)
Right. I think it should not suck. :)
really, the API is quite nice: all request-time functions are $r object methods. that's what makes the mod_perl wrapper for Apache as it exists now so great - it's Perlish.
That's fine with me. What I want is to put all the docs for those methods in Apache::RequestRec's POD, and not require users to load any other modules to get access to them. I think the approach I outlined in the other thread would work for the latter. I don't enough about how the doc generation works to know what's required for the POD.
doing something like Apache::RequestUtil::is_initial_req($r) (or whatever variant) is not very Perlish.
Neither is loading a bunch of modules that you don't actually access directly, 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.
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.
me neither. I do think they would understand it better if they looked at is
as a wrapper, though, but that's neither here nor there.
Incidentally, is there a decent tutorial for the apache 2 C API anywhere? The stuff I found on httpd.apache.org was pretty thin.
I think that's what users have now with $r.
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..
granted, $r is not a typical Perl object, but it can't be
I don't understand why.
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 always thought it was pointlessly dangerous to subclass $r in mp1, but I know people did it with alarming frequency.
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.
- Perrin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
