Dave Angel wrote: > Any time I see multiple lists like that which have to stay in > synch, I think code-smell. >
I don't think it is that bad, but I agree there is always room for improvement. > Why not let the EVT's be passed as strings, and avoid the whole mapping > to integers and mapping back detail? And name the methods involved in a > way that you can directly translate the string to the method name? > There is some merit in this. At present I am writing the server and the client, and copy/paste the list of constants, so they are guaranteed to stay in sync. (Maybe I should import it instead - even more fool-proof [the fool being me, of course]). However, it may happen that I want to open it up to 3rd-party clients in the future, in which case I would have to publish some sort of API. It would make more sense to identify the messages by a meaningful name rather than an integer. And yes, I could then use 'getattr' to retrieve the corresponding method on the server side. > Barring that, make a single "structure" which lists the event > names and > method names in matched pairs, and derive whatever lists and > dictionaries you actually need from that one structure. And that > structure should be shared between client and server code, > perhaps as a > text file that they both parse. Or as a stream that's passed > from one > to the other during startup. That way, consistency between > them can be > regulated (with version string in the file, for example) > I'm not sure how that would work. On the client side, I need to respond to a 'button-clicked' event from the gui system by sending an EVT_BUTTON_CLICKED message to the server. In other words it is hard-coded into the client program. I don't know how that would work if I read in a list of message-types at startup. > DaveA > Thanks for the input - it is always good to have some fresh ideas. Frank -- http://mail.python.org/mailman/listinfo/python-list