Greg Ewing wrote: > Antoine Pitrou wrote: > > >>button = gui.Button(...) >>button.on_clicked += my_on_clicked_button > > >>Has anyone had any experience with this idiom? Are there any drawbacks? >>It looks more elegant than inheritance and overriding methods to me. > > > PyGUI currently has a form of this, except that you > only get to plug in one handler at a time. This is > enough to avoid the need for subclassing in many > cases, though. > > I could support multiple handlers, but it would > make things substantially more complicated, and I'm > not convinced it's worth it. I rarely find the need > to install multiple independent handlers for an > event. Often I want to *override* a handler and > gain complete control, and then I find that > multiple-handler systems (e.g. gtk signals) tend > to hinder more than they help.
I use the .Net system quite a bit at work, so I'm familiar with the various use cases. It is true that most of the time, messages are sent to a single target. The most common use cases for multiple recievers, in my experience are: 1) Implementation of the Observer design pattern - that is, you have multiple views of a single model. (Now, its true that the event system used for view update notifications doesn't *have* to be the same one as is used for dispatching events from the UI, but its nice if there's a commonality between them.) 2) Message filtering via chained handlers. This of course requires that the handler have the ability to modify the message before its passed to the next handler. This can allow you to do things like add drag and drop support to a control that doesn't normally handle such things, or to add special types of tooltips. In the current system I'm working with, I use it for visual animation effects. -- Talin _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
