www.digitalmars.com         C & C++   DMDScript  

D - Throwable Events

reply Benji Smith <dlanguage xxagg.com> writes:
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
Dec 12 2003
next sibling parent Berin Loritsch <bloritsch d-haven.org> writes:
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.
Dec 12 2003
prev sibling next sibling parent reply Ilya Minkov <Ilya_member pathlink.com> writes:
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
Dec 12 2003
parent "Mark Brudnak" <malibrud provide.net> writes:
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
Dec 12 2003
prev sibling next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
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
Dec 12 2003
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
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
Dec 12 2003