GUI Library Evolution (Or, why we have "event" objects...)
Last update on .
This popped out of Matthew Scott's comment; seemed a little too involved to be writing in a comment (and it's a slow news day).
Context: I'd noted that Matthew's code wasn't using one of the strengths of PyDispatcher, particularly it's ability to allow for unifying parameter names and filtering out extraneous parameters before passing messages to their final destination. As a result, he'd explicitly mentioned the need to match up signal consumer and producer signatures.
To be concrete, with PyDispatcher, you can do this:
def someMethod( text ):
def someFunc( sender, text, date ):
def someOther( date ):
And then hook up all three functions to the same signal (which we will assume sends at least sender, text and date). PyDispatcher will only pass those parameters which match the parameter-names of the function's defined parameters.
So, a generic logging method might only look at the sender and the event, while something which wants to deal with the text produced by a particular button could just specify text.
Now, what problem does that solve?
Pingbacks are closed.
Comments are closed.