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

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

 exception handler is likely to have hard to predict results. Not that i

 understand the problem throrughly.

 The main difference, exceptions throw a program in an exceptional state,

 normal program flow may not happen, since it would have disasterous

 continue until the failure has been cured and normal state of the software

 reserved. On the contrary, you don't want an event handler to go off as

 an event, you want the current event handler to finish first. Thus events

 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

 Windows has corresponding functionality. You can simulate the user

 in a certain window by sending events, or you can recieve non-standard,
 non-windows events by a number. For example, "wintab" graphic tablet

 you connect to them, take your window handle, and then fire non-standard

 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

 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
  

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