On Wed, 19 Apr 2000, Ka-Ping Yee wrote:
object.denotify(message[, callback]) - Turn off notification.
You need to be a bit more careful here. What if callback is foo().function? It's unique, so I could never denotify it. A better way, and more popular (at least in the signal/slot terminology), is to return a cookie on connect, and have disconnect requests by a cookie.
object.send(message, **args) - Call all callbacks registered on object for message, in reverse order of registration, passing along message and **args as arguments to each callback. If a callback returns notifier.BREAK, no further callbacks are called.
When I implemented that mechanism, I just used a special exception (StopCommandExecution). I prefer that, since it allows the programmer much more flexibility (which I used)
(Alternatively, we could use signals/slots terminology: connect/disconnect/emit. I'm not aware of anything the signals/slots mechanism has that the above lacks.)
Me neither. Some offer a variety of connect-methods: connect after, connect-before (this actually has some uses). Have a short look at the Gtk+ signal mechanism -- it has all these.
1. The 'message' passed to notify/denotify may be a class, and the 'message' passed to send may be a class or instance of a message class. In this case callbacks registered on that class and all its bases are called.
This seems a bit unneccessary, but YMMV. In all cases I've needed this,
a simple string sufficed (i.e., method 2)
Implementation nit: I usually use
class _BREAK:
pass
BREAK=_BREAK()
That way it is gurranteed that BREAK is unique. Again, I use this mostly
with exceptions.
All in all, great idea Ping!
--
Moshe Zadka