Move dictionary from instance to class level
Frank Millman
frank at chagford.com
Thu Aug 27 03:10:02 EDT 2009
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
More information about the Python-list
mailing list