Ah! Of course. Thanks. I tend to prefer other techniques (like AFactory) over inheritance when possible, but since inheritance is the Twisted Way, I'll do it that way. Maybe this idiom should be added to plugin.html? Regards, Zooko
Zooko wrote:
Well, it'd also be nice to see coverage of when to implement a Service, what's involved in doing so, and all that .. maybe a higher level document about "Writing your application with Twisted" would be more appropriate for that though. - Bruce
On Thu, 25 Jul 2002 12:53:08 -0300, Zooko <zooko@zooko.com> wrote:
I agree with you (and I agree even more now than I did when I wrote Factory) but I think that Factory is one of those instances where "is-a" makes sense, if not inheritance. Really the way I'd do it now, starting from scratch, would be to have an interface which you either implement or provide an adapter for, that had the buildProtocol/doStart etc methods on it. The reason I say that is that the extra level of indirection (in AFactory) doesn't really provide for any interesting hooks; the object that is "building" the protocols is typically your user application. protocol.Factory is more like an interface that it implements than a class it should inherit from, but it does have the utility convenience of (doStart and doStop) -> (startFactory and stopFactory). As far as that doc goes... yes. We need it. -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |
Zooko wrote:
Well, it'd also be nice to see coverage of when to implement a Service, what's involved in doing so, and all that .. maybe a higher level document about "Writing your application with Twisted" would be more appropriate for that though. - Bruce
On Thu, 25 Jul 2002 12:53:08 -0300, Zooko <zooko@zooko.com> wrote:
I agree with you (and I agree even more now than I did when I wrote Factory) but I think that Factory is one of those instances where "is-a" makes sense, if not inheritance. Really the way I'd do it now, starting from scratch, would be to have an interface which you either implement or provide an adapter for, that had the buildProtocol/doStart etc methods on it. The reason I say that is that the extra level of indirection (in AFactory) doesn't really provide for any interesting hooks; the object that is "building" the protocols is typically your user application. protocol.Factory is more like an interface that it implements than a class it should inherit from, but it does have the utility convenience of (doStart and doStop) -> (startFactory and stopFactory). As far as that doc goes... yes. We need it. -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |
participants (3)
-
Bruce Mitchener -
Glyph Lefkowitz -
Zooko