[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