> 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]
