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
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).
>
>

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
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
> 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).
> >
> >
>
>

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