On Wed, Nov 05, 2008 at 07:24:31PM -0000, [EMAIL PROTECTED] wrote: > > I completely agree, architecturally speaking, for Twisted, that this is > a good idea. I already linked to > <http://twistedmatrix.com/trac/ticket/3205> in this thread, which is a > broad outline of my long-term plan to eliminate the reactor's singleton- > ness.
Thanks. I must have missed the link earlier. > On the other hand, the approach you're describing here, using Twisted > "just a little", starting up a reactor and spinning it in some obscure > corner of an application, is basically an architectural antipattern, > which should be avoided as much as possible. I agree that it should be avoided as much as possible, but I don't think that it should be impossible to do. Suppose, for example, that you are refactoring a project to use Twisted. It's nice to be able to use it just a little, then iteratively add more to it. I agree that you shouldn't stay in this state long, but it sure would be a nice crutch during refactoring. > I can definitely think of a few "larger projects" - names withheld to > protect the guilty - whose designs have been influenced and > rehabilitated by their decision to use Twisted. I worry about making it > easier to throw Twisted into a situation where it will make the overall > design of a system into even more of an incomprehensible mess. Just > imagine trying to decipher a GUI project using Twisted for networking, > where there are 3 or 4 different global reactors, each of which is used > by a different window or dialog box, and you have to figure out which > one you need based on what context your Twisted-using code is running > in. Give me any API, and I can create a program that misuses it. :) I'm guessing that the GUI project would be much more decipherable if instead of having 3 or 4 global reactors, there were 3 or 4 reactors that were nicely encapsulated. Anyway, if there's a good reason for having 3 or 4 reactors, I'm sure there's a good way to organize the code so that things don't get out of hand. I think the following use cases for mutliple reactors outweigh the potential risks: - starting and stopping a reactor multiple times, particularly for testing - making it easier to refactor existing code to use the reactor pattern - k threads that each have their own reactor And I'm sure we could come up with others. > It's nice to be able to say "you can't do that, it's impossible", when > someone asks how to set up something like that. If I wanted to be constantly told "you can't do that, it's impossible", I wouldn't be a Python guy. If I want to shoot myself in the foot, that's my problem. :) -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
pgpaLq1O9cWcv.pgp
Description: PGP signature
_______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
