Re: Theory of good signal/event API design?

[Federico Mena Quintero <federico ximian com>]

On Sun, 2007-09-16 at 18:28 +0200, Sander Marechal wrote:

> My question: How do I determine what signals/events I should send out so
> that together they make for a nice module API? For now, I am simply
> building modules and adding signals to the application as I need them,
> but I bet there is a better way to figure out which signals I should add
> and where I should add them.

You can think of signals in different ways:

* "Something happened" - an informational message.  "Oh, the Loader
object said 'finished', so it's done".  You'd then process the loaded
data or something.

* "I need something from somewhere" - an actual request that must be
handled.  "Oh, the HTMLWidget said 'load-image' and gave me a URI, so I
guess I should download that image and feed it to the widget".

* "Something bad happened" - an error in an object that handles a
long-running process.  "Oh, the ImageDecoder emitted 'error' with a
CORRUPTED_DATA argument, so that image file must be broken".

* etc.

So you can have signals that are hooks for expansion, actual requests
for information, simple notifications, etc.

One big thing to think about when you have signals is whether your
object should be reentrant.  What happens if someone calls a method on
your object from a signal handler for that object?  Should the object
support it or not?  Does it need to support at least minimal reentrancy
(e.g. to let you call foo_delete_item() when you are inside a
foo::item_inserted signal handler)?

  Federico