• Benji Smith <dlanguage xxagg.com> Dec 13 2003
• "Ben Hinkle" <bhinkle4 juno.com> Dec 14 2003
• "Ben Hinkle" <bhinkle4 juno.com> Dec 14 2003
• Andy Friesen <andy ikagames.com> Dec 14 2003
• Georg Wrede <Georg_member pathlink.com> Dec 14 2003
• Benji Smith <dlanguage xxagg.com> Dec 15 2003
• Lewis <dethbomb hotmail.com> Dec 18 2003

Thanks to those who responded to my "Throwable Events" thread. Since I don't
know much about the technical implementation of exception handling, I wasn't
aware of the problems that might be caused by events being thrown.

Nevertheless, I still think it's totally appropriate for the D language to
include some kind of built-in event handling functionality. I've read about QT's
signal/slot mechanism before (though I've never used it), and it sounds
intriguing.

A central event queue also sounds like it would fit the bill.

And I'm sure there are a number of other event-handling paradigms that would
serve our needs well.

But the notion of an event, with a sender and a recipient, is such a common
programming idiom that it seems like it should be implemented as part of the
language. Or, at the very least, it should be in the standard library with
special back-end support (much like the GC is implemented in the standard
library, but it's also part of the language).

I agree a standard API for keeping track of listeners on a given object for
a given event and firing the event would be nice.but does it have to be in
the language? It seems much better suited to Phobos. Is there a syntax
issue?  For Java's listener API see the Java class
javax.swing.event.EventListenerList
http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/event/EventListenerList.
html

Also, posting an event to a queue (like the OS does with the window event
queue) and later dispatching that event from the event thread is much
different than a simple "call all the listeners" mechanism.  I'm not so sure
about how often a standard event queue would get used.... after all the OS
keep track of the most important one(s).

-Ben


"Benji Smith" <dlanguage xxagg.com> wrote in message
news:brh4ab$132h$1 digitaldaemon.com...
 Thanks to those who responded to my "Throwable Events" thread. Since I


 know much about the technical implementation of exception handling, I


 aware of the problems that might be caused by events being thrown.

 Nevertheless, I still think it's totally appropriate for the D language to
 include some kind of built-in event handling functionality. I've read


 signal/slot mechanism before (though I've never used it), and it sounds
 intriguing.

 A central event queue also sounds like it would fit the bill.

 And I'm sure there are a number of other event-handling paradigms that


 serve our needs well.

 But the notion of an event, with a sender and a recipient, is such a


 programming idiom that it seems like it should be implemented as part of


 language. Or, at the very least, it should be in the standard library with
 special back-end support (much like the GC is implemented in the standard
 library, but it's also part of the language).

Actually now that I think about it the API could just be managing an array
(or hashtable) of delegates. A class, say, DelegateTable (not to be confused
with "delectable") that looks in pseudo-code something like:

 interface EventInfo {};
 class DelegateTable {
   alias void delegate(EventInfo) EventListener;
   EventListener[EventListener] ht;
   DelegateTable{...}
   void add(EventListener dg) {ht[dg] = dg;}
   void remove(EventListener dg) {delete ht[dg];}
   void throwEvent(EventInfo event) {
      EventListener[] vals = ht.values;
      for (int i=0; i < vals.length; i++) {
         vals[i](event);
      }
   }

A user of this class would have something like:

 class Test {
   class FooEvent EventInfo {...}
   class BarEvent EventInfo {...}
   DelegateTable fooListeners;
   DelegateTable barListeners;

   void addFooListener(EventListener dg) {fooListeners.add(dg);}
   void addBarListener(EventListener dg) {barListeners.add(dg);}
   void fireFoo() {
      FooEvent event = ...make a FooEvent...
      fooListeners.throwEvent(event);
   }
   void fireBar() {
      BarEvent event = ...make a BarEvent...
      barListeners.throwEvent(event);
   }

Are delegates hashable? Can you compare delegates? I haven't tried.

-Ben

"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:brhp4j$21j8$1 digitaldaemon.com...
 I agree a standard API for keeping track of listeners on a given object


 a given event and firing the event would be nice.but does it have to be in
 the language? It seems much better suited to Phobos. Is there a syntax
 issue?  For Java's listener API see the Java class
 javax.swing.event.EventListenerList


 html

 Also, posting an event to a queue (like the OS does with the window event
 queue) and later dispatching that event from the event thread is much
 different than a simple "call all the listeners" mechanism.  I'm not so


 about how often a standard event queue would get used.... after all the OS
 keep track of the most important one(s).

 -Ben


 "Benji Smith" <dlanguage xxagg.com> wrote in message
 news:brh4ab$132h$1 digitaldaemon.com...
 Thanks to those who responded to my "Throwable Events" thread. Since I


 know much about the technical implementation of exception handling, I


 aware of the problems that might be caused by events being thrown.

 Nevertheless, I still think it's totally appropriate for the D language




 include some kind of built-in event handling functionality. I've read


 signal/slot mechanism before (though I've never used it), and it sounds
 intriguing.

 A central event queue also sounds like it would fit the bill.

 And I'm sure there are a number of other event-handling paradigms that


 serve our needs well.

 But the notion of an event, with a sender and a recipient, is such a


 programming idiom that it seems like it should be implemented as part of


 language. Or, at the very least, it should be in the standard library




 special back-end support (much like the GC is implemented in the




 library, but it's also part of the language).

Benji Smith wrote:
 Thanks to those who responded to my "Throwable Events" thread. Since I don't
 know much about the technical implementation of exception handling, I wasn't
 aware of the problems that might be caused by events being thrown.
 
 Nevertheless, I still think it's totally appropriate for the D language to
 include some kind of built-in event handling functionality. I've read about
QT's
 signal/slot mechanism before (though I've never used it), and it sounds
 intriguing.
 
 A central event queue also sounds like it would fit the bill.
 
 And I'm sure there are a number of other event-handling paradigms that would
 serve our needs well.
 
 But the notion of an event, with a sender and a recipient, is such a common
 programming idiom that it seems like it should be implemented as part of the
 language. Or, at the very least, it should be in the standard library with
 special back-end support (much like the GC is implemented in the standard
 library, but it's also part of the language).


Event handling is really, really easy to do within the language.  I 
don't see why it needs any special support.  Since delegates are a part 
of the language, implementing events is trivial:

http://ikagames.com/andy/d/listener.d

It's just a sequence of delegates.  When the Listener is called (via 
opCall), every delegate within the sequence is called.  It's almost 
identical to C#'s builtin event construct in use.

  -- andy

In article <brh4ab$132h$1 digitaldaemon.com>, Benji Smith says...
But the notion of an event, with a sender and a recipient, is such a common
programming idiom that it seems like it should be implemented as part of the
language. Or, at the very least, it should be in the standard library with
special back-end support (much like the GC is implemented in the standard
library, but it's also part of the language).


I may be totally off here, but I'd see the main use of an event queue
as something where you place messages (or events) with no recipient.
Like "I've got ice cream, who wants some?" or "he inserted the floppy
drive in the bay".

This would make the object instances "live" in a new way.

In article <briatf$2s8q$1 digitaldaemon.com>, Georg Wrede says...
In article <brh4ab$132h$1 digitaldaemon.com>, Benji Smith says...
But the notion of an event, with a sender and a recipient, is such a common
programming idiom that it seems like it should be implemented as part of the
language. Or, at the very least, it should be in the standard library with
special back-end support (much like the GC is implemented in the standard
library, but it's also part of the language).


I may be totally off here, but I'd see the main use of an event queue
as something where you place messages (or events) with no recipient.
Like "I've got ice cream, who wants some?" or "he inserted the floppy
drive in the bay".


This is exactly what I was talking about.

It's easy to send an event (via a delegate) when the sender and recipient of the
event are both known beforehand.

But sometimes, you know the sender but not the recipient. Or sometimes you know
the recipient but not the sender. In cases like that, it might be nice to have a
mechanism for "broadcasting" events from one object. Any other objects that
might be interested in such an event could listen for that broadcast.

Benji Smith wrote:
 In article <briatf$2s8q$1 digitaldaemon.com>, Georg Wrede says...
 
In article <brh4ab$132h$1 digitaldaemon.com>, Benji Smith says...

But the notion of an event, with a sender and a recipient, is such a common
programming idiom that it seems like it should be implemented as part of the
language. Or, at the very least, it should be in the standard library with
special back-end support (much like the GC is implemented in the standard
library, but it's also part of the language).


I may be totally off here, but I'd see the main use of an event queue
as something where you place messages (or events) with no recipient.
Like "I've got ice cream, who wants some?" or "he inserted the floppy
drive in the bay".


 
 This is exactly what I was talking about.
 
 It's easy to send an event (via a delegate) when the sender and recipient of
the
 event are both known beforehand.
 
 But sometimes, you know the sender but not the recipient. Or sometimes you know
 the recipient but not the sender. In cases like that, it might be nice to have
a
 mechanism for "broadcasting" events from one object. Any other objects that
 might be interested in such an event could listen for that broadcast.
 
 


sounds very similar to the com+ subscriber/publisher paradigm except with
anonymity