[Divunal-author] Charge interfaces

Christopher Armstrong radix@twistedmatrix.com
Mon, 12 May 2003 15:09:33 -0400


On 2003.05.12 00:06, Allen Short wrote:
> >>>>> "Christopher" == Christopher Armstrong <radix@twistedmatrix.com> writes:
> 
>     > The only alternative I have come up with is rather lame: There
>     > will only be IChargeSource and IChargeSink interfaces, and
>     > they'll both define a `getShape' method (or maybe getSinkShape
>     > and getSourceShape, because some objects will probably want to
>     > implement both source and sink in the same class). Each
>     > implementation of these interfaces will check to make sure that
>     > the opposite is a compatible shape, which could just be a
>     > string. I actually partially implemented this, but it smelled
>     > bad so I threw it out. But now that I've run into the problem
>     > with the `connect' action, it seems to be the only way to do it.
> 
> Hmm. I didn't smell it, but from here that doesn't sound so bad. That
> way you keep your "charge source/sink compatibility" issues neatly
> tucked into a couple components and dont have to fight with the
> components system to get stuff like multiple sources/sinks working.

I implemented it. You only need a single IChargeSource and IChargeSink
per Thing, even if you want multiple conceptual sources and sinks on
a single object: You just need to implement sinkTo and gotSourced in a
way that can handle multiple objects. Also, I put a `supports(sinkTypes)'
method on Source, and a `getShapes' method on Sink. the result of getShapes
gets passed to supports, and the default implementation of supports returns
true if any of the items in self.compatibleSinks are in sinkTypes.

Oh, and rather than returning strings from getShapes, I'm returning classes.
I couldn't live without knowing that the types have an identity :)

Oh, and I also implemented `Touch' and `Zap' actions. `Touch' allows current
to go from your finger to a device, and `Zap' forces 20 charges into the 
device. TODO: Connect(ing a battery to a battery charger, e.g.).

On a related topic, I'd like people to comment on the large docstring I have
at the top of charge.py. It's just some rambling about a request/response
versus a current-based charge system.

-- 
 Twisted | Christopher Armstrong: International Man of Twistery
  Radix  |          Release Manager,  Twisted Project
---------+     http://twistedmatrix.com/users/radix.twistd/