[Python-Dev] Generic notifier module
Moshe Zadka
Moshe Zadka <mzadka@geocities.com>
Thu, 20 Apr 2000 09:09:45 +0300 (IDT)
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 <mzadka@geocities.com>.
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com