Is this..... evil?

Philip Swartzleonard starx at pacbell.net
Sat Feb 9 16:08:15 EST 2002


Joshua Muskovitz || Sat 09 Feb 2002 12:55:09p:

> My suggestion would be for each type of receiver to simply create its
> own dict which maps message types (strings) to local functions.  If
> it's in the dict, then you can assume its callable, and thus avoid the
> logic per incoming message.  If you set up your constructors correctly,
> you could even inherit the list of existing handlers from the base
> classes.  Thus class BaseReceiver could create the dict which handles
> the MsgA and MsgB types.  A derived class could add a MsgC handler to
> the dict, etc.  This also allows derived classes to "overload" base
> handlers by simply replacing the function reference in the dict.
> 
> something like (coded off the top of my head, if it don't run, sorry
> :-) 

Aside from missing a __ on an init, i sure as hell can't see any errors :)
 
> class Receiver:
>     def __init__(self):
>         self.msgFuncs = {}
> 
>     def message(self, msg):
>         if self.msgFuncs.has_key(msg.type):
>             self.msgFuncs[msg.type](msg)
> 
> class F(Receiver):
>     def __init__(self):
>         Receiver.__init__(self)
>         self.msgFuncs['fighto'] = rec_fighto
> 
>     def rec_fighto(self, msg):
>         ...
> 
> class S(Receiver):
>     def __init(self):
>         Receiver.__init__(self)
>         self.msgFuncs['spello'] = rec_spello
>         self.msgFuncs['fighto'] = rec_fighto
>         self.msgFuncs['none'] = rec_none
> 
>     ...
> 
> There are better ways to handle the dict adds, of course, but you get
> the idea.  The cool thing about this is that on a per receiver basis
> you can have different classes of messages still handled by a single
> common handler (just point them to the same internal function).

Hm, well, i do like the idea of being able to point different messages at 
the same handler... I figured i would do that kind of stuff by modifing 
certain 'message' methods. I think what i want is to have the system as 
transparent as possible... but of course i don't really ever seem to know 
what i want untill i go and do it -some- way :)

Oh, and i don't really need the callable logic i don't think; it would be 
better to just make a project rule: 'dont ever name anything rec_xxx unless 
it's a function taking a message, unless you want to hurt yourself.' There 
really shouldn't be a reason to...

Thanks for the ideas... even if it doesn't change my mind i think it makes 
me realize in less vague terms why i want to do it a different way :)

Ja ne *sneeze*
 
> --
> lyyrs('Hire me!  I need the work!')
llyrs('Sorry just a semi poor college student here') ;)
-- 
Philip Sw "Starweaver" [rasx] :: www.rubydragon.com



More information about the Python-list mailing list