> On Jul 15, 2016, at 6:02 AM, Amber Hawkie Brown <hawk...@atleastfornow.net> > wrote: > > (disclaimer: this is after several hours on an aeroplane, this may all be > nonsense) > > So, I'm currently looking into adding some features to twisted.web -- > something that historically hasn't had the best support for pluggable > reactors, and which requires levels and levels of monkeypatching (see the top > level of > https://github.com/twisted/twisted/compare/trunk...deferreds-in-resrender-3711 > ). So, I was thinking, what if we made a new way for things to get their > reactor, rather than extending all these concrete implementations everywhere? > > Currently, you'd pass a reactor instance through to protocols by making the > factory understand it, and the protocol calling self.factory._reactor or > whatever. I never thought this was a supremely helpful or useful interface -- > especially for one-shot classes -- so what if instead we made a new > IProtocol-extending interface, which signals to tcp.Port/etc that the > protocol, once created, should have a reactor set on it (maybe through some > "setConnectingReactor" or something). This would mean that the factory > doesn't know about the reactor in most cases (with things like HTTPFactory > doing logging as an exception) -- but we could also have an > IClient/ServerFactoryWithReactor, that Endpoints (which needs to know about > the reactor, and which reactor it is listening on) can then check for and > call a similar function, telling the Factory what reactor it is actually > running under. > > This, I think, would reduce a bunch of duplicate code in __init__s of > factories, and could be implemented in the base class of Protocol or > ServerFactory, possibly. What do people think?
First off, I think a clearer articulation of the problem would be helpful :). Is it "I don't want to take parameters in __init__"? Or "I don't want to have duplicated code to grab the global reactor everywhere, but I still want to grab the global reactor everywhere"? Is it "most factories don't need the reactor except to hand it to their protocols, therefore they shouldn't have to have code to deal with it at all"? I definitely don't think we should address any of these issues with 'setConnectedReactor'. This is using a side-effect rather than just constructing the object with the things that it needs. We also shouldn't do it with a base class. Depending even more on inheritance would be movement in the wrong direction. If we want to address the issue of duplicated code in constructors, how about something like a @reactorParameter(name='reactor') decorator, which does the grab-the-current-global-reactor-if-it's-not-passed thing? A better pattern is 'just pass in the reactor', of course. Or, perhaps what you want is this 7-year-old ticket? :) https://twistedmatrix.com/trac/ticket/3205 -glyph _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
