Another interesting subject of debate, that unfortunately often gets hidden behind the opinions of biased people (with, say, commercial interests in one of the two).

The design problem is this: how to allow users to register a handler for
asynchronous events
Two alternative approaches exist:

class SomeComponent
{
    // 1. using delegates
    void registerForEvents( delegate handler )

    // 2. using interfaces
    void registerForEvents( interface handler )
}

I argue that neither approach is better or more simple or more expressive than the other, it depends on the use case

1) When the component supports a single event (say 'OnTimer') and you don't
need any context to handle it, use a delegate
2) When the single OnTimer event must be handled by a specific object (e.g.
it represents a timeout on one of multiple connections), use an interface.
     In this case implemented by the Connection class. The context ('this')
can then be used inside the handler function of the connection
3) When the component supports multiple kinds of events, and the client is
required to handle them all, use an interface.
    An interface can define a group of related handler functions, and forces
the user to implement them all.
4) When the component supports multiple events, but some clients are only
interested in one or few of those, use a delegate for each separate event.
    This avoids the well-known 'Java Adapter' problem where you need to
provide an empty implementation for all interface methods, and override
    only the ones you want to handle.
5 [ maybe you can think of more cases ]

So D (and any other useful programming language) should offer support for both, and programmers should decide on a case-by-case basis which one to use

As for "signals and slots", to me that seems different terminology for the same issue. A "signal" is a stateless event originally coming from Unix AFAIK (typical example being the 'kill' signal), with an implicit context being the application that receives the signal. "delegate" seems to be corresponding language concept usable to implement it. "slot" would then be the handler function itself. It's nothing new though, and delegates & interfaces are more generic: they can have parameters (state)

"Jeroen van Bemmel" <someone@somewhere.com> wrote in message news:bjclj0$1vgq$1@digitaldaemon.com...
> Another interesting subject of debate, that unfortunately often gets
hidden
> behind the opinions of biased people (with, say, commercial interests in
one
> of the two).
>
> The design problem is this: how to allow users to register a handler for
> asynchronous events
> Two alternative approaches exist:
>
> class SomeComponent
> {
>     // 1. using delegates
>     void registerForEvents( delegate handler )
>
>     // 2. using interfaces
>     void registerForEvents( interface handler )
> }
>
> I argue that neither approach is better or more simple or more expressive than the other, it depends on the use case
>
> 1) When the component supports a single event (say 'OnTimer') and you
don't
> need any context to handle it, use a delegate
> 2) When the single OnTimer event must be handled by a specific object
(e.g.
> it represents a timeout on one of multiple connections), use an interface.
>      In this case implemented by the Connection class. The context
('this')
> can then be used inside the handler function of the connection
> 3) When the component supports multiple kinds of events, and the client is
> required to handle them all, use an interface.
>     An interface can define a group of related handler functions, and
forces
> the user to implement them all.
> 4) When the component supports multiple events, but some clients are only
> interested in one or few of those, use a delegate for each separate event.
>     This avoids the well-known 'Java Adapter' problem where you need to
> provide an empty implementation for all interface methods, and override
>     only the ones you want to handle.
> 5 [ maybe you can think of more cases ]
>
> So D (and any other useful programming language) should offer support for both, and programmers should decide on a case-by-case basis which one to
use
>
> As for "signals and slots", to me that seems different terminology for the same issue. A "signal" is a stateless event originally coming from Unix AFAIK (typical example being the 'kill' signal), with an implicit context being the application that receives the signal. "delegate" seems to be corresponding language concept usable to implement it. "slot" would then
be
> the handler function itself. It's nothing new though, and delegates & interfaces are more generic: they can have parameters (state)
>
>
>

A signal and slot mechanism is a terminology that has been established after the wide Qt usage, especially with KDE. A signal is a collection of slots, not a delegate. A delegate is nothing but an object pointer + method pointer which allows the object to be called. In that sense, a slot is a delegate. The Interface solution is an alternative to multiple inheritance and its implementation difficulties. Interfaces can't be compared to delegates, its like apples and oranges: interfaces is for inheritance, delegates are for callbacks.

The D language needs direct support for this.