[Twisted-Python] Components

[Christopher Armstrong]

Glyph Lefkowitz wrote:
> On Thu, 2004-02-26 at 14:59, Phillip J. Eby wrote:
>>Yep, just subclass InterfaceClass and add a __call__ method that calls back 
>>to adapt() and you'd be all set.  One other benefit to PyProtocols is that 
>>you can track what interfaces an *instance* supports, independent of what 
>>its class supports.
> 
> Would you consider adding this to PyProtocols directly?  If we're going
> to maintain a component system as part of Twisted, I would like to at
> least get the benefit of having full control over the component system
> within Twisted.  I don't want to have some people using PyProtocols and
> others using PyProtocols+TwistedHacks.

Interface calling isn't that big of a deal. It just means for 
*parameterized* interfaces, we can't rely on calling (if we want to 
support non-Twisted interfaces there). But when we're adapting to a 
particular interface that we know subclasses our CallableInterface, we 
can call it.

> There are a lot of features I'd add to Twisted's component system if I
> had time, such as:

In the following, "components system" = "PyProtocols".

> 	- implicit context-dependent location of closest running t.a.service
> services by interface

Doesn't require changes to the components system

> 	- interface-based context (moshez's context trick)

Doesn't require changes to the components system

> 	- automatic generation of interfaces from any class

Doesn't require changes to the components system (afaict)

> 	- IComponentized

Hmm, what exactly is the use case for this anyway? I thought it was 
related to string registration of adapters. It doesn't sound like it 
really requires changes to the components system, either; Componentized 
seems like it could easily be implemented on top of PyProtocols.

> 	- context / interface based log separations

I don't really understand this, but it doesn't sound like it requires 
changes to the components system.

> And of course, integrating foom's string-based components would be great
> too.  There is a lot of friction even to add something like this to
> Twisted.  I imagine that adding something like this to PyProtocols, with
> potentially more projects out there depending on the exact specifics of
> all its semantics, would be even worse.

Well, Bob said in another message that he had already done 
string-registration of adapters successfully. (?)

> The other alternative is to add a bunch of specific hacks to PyProtocols
> that get loaded only when Twisted gets loaded, which could potentially
> introduce compatibility problems with other PyProtocols-using code,
> which would sort of invalidate the whole point of using a common
> components system in the first place.

My previous retorts make this point of yours irrelevant for the moment, 
so I will not respond: if you want, you may debate my retorts and we can 
get to this point once we have worked those out.[1]

[1] I need to figure out a succinct way to say this. Maybe some Latin 
crap. It's way too verbose. spiv suggested "ad nauseum" when I asked 
him... Better look that one up. ;-)

> Then we have the issue of the PyProtocols dependency; dependency
> management can be quite hairy on windows.

Hmm, yeah, I assumed we would include our own (hopefully unhacked) copy 
of PyProtocols in releases.

> Maybe I'm alone in these concerns, though.  Does anyone else feel that
> depending on PyProtocols would increase the learning curve for Twisted
> even more?  Or is this common knowledge in the Python community that
> could be leveraged to actually make the curve shallower?  I can
> certainly learn to wrap my head around the whole thing if nobody else
> has trouble with it :)

I kinda hold this reservation. PyProtocols is VERY complex compared to 
the t.p.c components system. But maintaining our own inadequate version 
is pretty sucky.

>>There might be some other issues that could come up, but I'm definitely 
>>willing to try to "adapt" to Twisted's needs in these areas, especially if 
>>it means I could get rid of PyProtocols' wrapper code and wrapping tests 
>>for Twisted's existing interface class.  :)
> 
> 
> This is clearly something that we need to talk about more.  As many
> silly disagreements about design as I can come up with, a common
> components system would be beneficial to everyone involved.  Are you
> coming to PyCon? :)

PyCon! PyCon! Everybody come to PyCon!

-- 
  Twisted | Christopher Armstrong: International Man of Twistery
   Radix  |          Release Manager,  Twisted Project
---------+           http://radix.twistedmatrix.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: </pipermail/twisted-python/attachments/20040226/9a29e159/attachment.sig>