I've been doing some GUI development in my other life, away from D, and I've been thinking about event handling and how I'd ideally like event handling to happen.

It seems like it would be really nice to make the widget throw an event, much like you'd throw an exception. Somewhere upstream, the event has to be caught and handled by an event handler.

It just seems to me that the throw/catch idiom would work really well for events in a GUI.

And then, when I got to thinking about it, it occurred to me that it would be nice to throw events, even when not working with a GUI. I don't have any specific examples in mind, but I'd like to hear opinions from anyone who's interested.

--Benji

Benji Smith wrote:

> I've been doing some GUI development in my other life, away from D,
> and I've been thinking about event handling and how I'd ideally like
> event handling to happen.
> 
> It seems like it would be really nice to make the widget throw an
> event, much like you'd throw an exception. Somewhere upstream, the
> event has to be caught and handled by an event handler.
> 
> It just seems to me that the throw/catch idiom would work really well
> for events in a GUI.
> 
> And then, when I got to thinking about it, it occurred to me that it
> would be nice to throw events, even when not working with a GUI. I
> don't have any specific examples in mind, but I'd like to hear
> opinions from anyone who's interested.

In the Java world we call this an EventBuss.  All classes that are
interested subscribe to the buss, and the events received by any particular
class are filtered by the type of event or any other criteria.

For example, a typical event buss would have an interface similar to this:

EventBus
{
    subscribe( Subscriber subscriber, Class eventType, EventFilter filter );
    unsubscribe( Subscriber subscriber, Class eventType, EventFilter filter );

    publish( EventObject event );
}

Subscriber
{
    inform( EventObject event );
}

EventFilter
{
    boolean accept( EventObject event );
}

It works quite well in fact.  It is probably the closest thing to event throwing
as you can safely get--and is eminently more useable.

For example, publishing an event will be able to notify classes that are not
directly in the call stack of a particular event.

Throwing an event like throwing an exception necessarily means that the language
would have to propogate the event *up* the callstack until it is handled.  The
default handler should probably ignore the event because it is not an exception.
But the main reason for events is to kick off processes in response to some type
of ineraction.  For instance, if a user clicks a button, the event triggered by
that action might set in motion three different actions--none of which are are
in the call stack.

That is why the flexibility of the EventBus is much better in this case.

In article <ag0ktvoc74h7tqt981qo5e5g5t504h1fof@4ax.com>, Benji Smith says...
>It just seems to me that the throw/catch idiom would work really well for events in a GUI.

Maybe yes, but technically it's infeasible. You should never ever throw exceptions from anything going upwards the stack. Throwing an exception from an exception handler is likely to have hard to predict results. Not that i would understand the problem throrughly.

The main difference, exceptions throw a program in an exceptional state, where normal program flow may not happen, since it would have disasterous results to continue until the failure has been cured and normal state of the software is reserved. On the contrary, you don't want an event handler to go off as you send an event, you want the current event handler to finish first. Thus events are added in the event queue and processed one after each other.

It makes sense to register custom event types, and to be able to send events. Windows has corresponding functionality. You can simulate the user pressing keys in a certain window by sending events, or you can recieve non-standard, non-windows events by a number. For example, "wintab" graphic tablet drivers, if you connect to them, take your window handle, and then fire non-standard events on your window, which you can interpret as pen/puck actions taking place.

The only difference which should be made in D, is that Events should be denoted by a hierarchy of objects instead of numbers.

-eye

This sounds at first glance suspiciously similar to Windows message handling.  Sending an event WM_BROADCAST perhaps.  For situations where you do not know who will handle the event.

Sean

"Benji Smith" <dlanguage@xxagg.com> wrote in message news:ag0ktvoc74h7tqt981qo5e5g5t504h1fof@4ax.com...
> I've been doing some GUI development in my other life, away from D, and I've been thinking about event handling and how I'd ideally like event handling to happen.
>
> It seems like it would be really nice to make the widget throw an event, much like you'd throw an exception. Somewhere upstream, the event has to be caught and handled by an event handler.
>
> It just seems to me that the throw/catch idiom would work really well for events in a GUI.
>
> And then, when I got to thinking about it, it occurred to me that it would be nice to throw events, even when not working with a GUI. I don't have any specific examples in mind, but I'd like to hear opinions from anyone who's interested.
>
> --Benji

I think what Benji is suggesting is an alternative to the callback.  That is, to provide another mechanism for a lower level module to call a higher level module to notify it of an event.  Since direct calls from low-level modules to high level modules is generally frowned upon because it creates circular dependencies among modules, the callback is used.  The problem with callbacks is that the lower level module must actively manage the registration of the callbacks and make sure that it does not call a NULL delegate.

It would be nice if a low-level class could request service from its calling function by throwing something (not an exception) which could service it synchronously.

This is what Qt does with signals and slots.

Mark.


"Ilya Minkov" <Ilya_member@pathlink.com> wrote in message news:brd9os$hjv$1@digitaldaemon.com...
> In article <ag0ktvoc74h7tqt981qo5e5g5t504h1fof@4ax.com>, Benji Smith
says...
> >It just seems to me that the throw/catch idiom would work really well for events in a GUI.
>
> Maybe yes, but technically it's infeasible. You should never ever throw exceptions from anything going upwards the stack. Throwing an exception
from an
> exception handler is likely to have hard to predict results. Not that i
would
> understand the problem throrughly.
>
> The main difference, exceptions throw a program in an exceptional state,
where
> normal program flow may not happen, since it would have disasterous
results to
> continue until the failure has been cured and normal state of the software
is
> reserved. On the contrary, you don't want an event handler to go off as
you send
> an event, you want the current event handler to finish first. Thus events
are
> added in the event queue and processed one after each other.
>
> It makes sense to register custom event types, and to be able to send
events.
> Windows has corresponding functionality. You can simulate the user
pressing keys
> in a certain window by sending events, or you can recieve non-standard, non-windows events by a number. For example, "wintab" graphic tablet
drivers, if
> you connect to them, take your window handle, and then fire non-standard
events
> on your window, which you can interpret as pen/puck actions taking place.
>
> The only difference which should be made in D, is that Events should be
denoted
> by a hierarchy of objects instead of numbers.
>
> -eye
>
>

Benji Smith wrote:

>I've been doing some GUI development in my other life, away from D,
>and I've been thinking about event handling and how I'd ideally like
>event handling to happen.
>
>It seems like it would be really nice to make the widget throw an
>event, much like you'd throw an exception. Somewhere upstream, the
>event has to be caught and handled by an event handler.
>
>It just seems to me that the throw/catch idiom would work really well
>for events in a GUI.
>
>And then, when I got to thinking about it, it occurred to me that it
>would be nice to throw events, even when not working with a GUI. I
>don't have any specific examples in mind, but I'd like to hear
>opinions from anyone who's interested.
>
>--Benji
>  
>
Some standard mechanism would be nice.  I used event handling in my last game, using a queue.  ie when a player got killed, reached a certain part in the map, collided with the enemy, ect... it would cause an event.  It would be nice if I didn't have to create the mechanism myself (easy as it is).

-Anderson