• Benji Smith <dlanguage xxagg.com> Dec 12 2003
• Berin Loritsch <bloritsch d-haven.org> Dec 12 2003
• Ilya Minkov <Ilya_member pathlink.com> Dec 12 2003
• "Mark Brudnak" <malibrud provide.net> Dec 12 2003
• "Sean L. Palmer" <palmer.sean verizon.net> Dec 12 2003
• J Anderson <REMOVEanderson badmama.com.au> Dec 12 2003

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

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.

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

"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

"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

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