On Mon, Jan 05, 2004 at 06:59:26PM -0800, JD wrote:
That's what I thought. Did you take a look at that code sample I sent earlier? I hacked that up myself, with few examples, so I can see where i might have put things in places they weren't intended to be.
I did. The basic idea seemed fine, except for the trivial flaws I pointed out. I don't have time to test and debug your code for you, though, especially when it's obvious you haven't tried to do so either. If your code isn't working, then it would help us if you could specify *how* it isn't working, i.e. what error or misbehaviour you are seeing. Your previous mail didn't indicate that you'd tested the example code you sent (and the trivial syntax errors suggest this is also the case).
Also, good style suggests that you probably shouldn't mix your application code with your IRCClient extensions, i.e. subclass IRCClient for WHO support (and other other unimplemented commands you need), and then subclass that for your application.
I don't quite understand. Because in my case, my application just intantiates a client long enough to extract some information from the IRC server, issue a "who" command and extract the data.
I always thought it was appropriate to sub-class the part i want to do, or parts that are not implemented by the parent, as in my case of wanting to do the "who" command, so I treated the command like any other IRC command that issues commands and gets back data.
So If I can't mix my application code with a sub_class of a IRCClient, then how is the right way to do it.
What I was trying to say is rather than subclass like this: IRCClient (from twisted.protocols.irc) | \--YourIRCApp (adds WHO command, has your application logic) It might be a better idea to do it like this: IRCClient (from twisted.protocols.irc) | \--ExtendedIRCClient (adds WHO command) | \--YourIRCApp (has your application logic) But that's really just a cosmetic issue. In an ideal world, Twisted would already have the WHO command implemented in its standard IRCClient. Until we reach that point, though, I still like the idea of keeping the protocol implementation and the application using that protocol seperate, even if the "protocol implementation" part of that picture is currently split between what Twisted already provides (IRCClient) and what you need to add (what I called ExtendedIRCClient above). Or you could not implement WHO yourself at all, and use the more complete IRC implementation in irc2.py... -Andrew.