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

Reply via email to