In article <bul743$2ggn$1@digitaldaemon.com>, davepermen says...
>
>But i think there should be one change done right from the start: use delegates, not listeners. This is NOT an optimisation, but such a general design issue, i think it should be done right from the start.

Would it be possible to explain in a few lines of D how you would implement the listener functionality with delegates?

well.. something like this:

Window win = new Window("Title");
win.onClose = delegate void() {
    app.postQuitMessage();
}

not sure about the syntax again, i always mix delegate void() and void
delegate() :D

now, for the implementation, it would look like this:

class Window {
    /*....*/
    void delegate() onClose;
}

and in the event handler (win32 here)

case WM_CLOSE:
     if(curWin.onClose !== null) curWin.onClose();
     break;



something in that idea..

"Georg Wrede" <Georg_member@pathlink.com> schrieb im Newsbeitrag news:bulgt3$30s1$1@digitaldaemon.com...
> In article <bul743$2ggn$1@digitaldaemon.com>, davepermen says...
> >
> >But i think there should be one change done right from the start: use delegates, not listeners. This is NOT an optimisation, but such a general design issue, i think it should be done right from the start.
>
> Would it be possible to explain in a few lines of D how you would implement the listener functionality with delegates?
>
>

In article <bulgt3$30s1$1@digitaldaemon.com>, Georg Wrede says...
>
>In article <bul743$2ggn$1@digitaldaemon.com>, davepermen says...
>>
>>But i think there should be one change done right from the start: use delegates, not listeners. This is NOT an optimisation, but such a general design issue, i think it should be done right from the start.
>
>Would it be possible to explain in a few lines of D how you would implement the listener functionality with delegates?
>

Try to look at Andy's dfbth.
I just browse it but looks quite simple and to the point.
I'm going to change DUI to a very similar scheme.

We should decide on listener(no) versus delegates(yes)
from the begining.

Ant

In article <buls8d$gdi$1@digitaldaemon.com>, Ant says...
>
>We should decide on listener(no) versus delegates(yes)
>from the begining.

Ok, so have I missed the main tradeoffs?

Georg Wrede wrote:
> In article <bul743$2ggn$1@digitaldaemon.com>, davepermen says...
> 
>>But i think there should be one change done right from the start: use
>>delegates, not listeners. This is NOT an optimisation, but such a general
>>design issue, i think it should be done right from the start.
> 
> 
> Would it be possible to explain in a few lines of D how you would
> implement the listener functionality with delegates? 
> 

I've written a nifty little template class that wraps a collection of delegates into a single callable entity. <http://ikagames.com/andy/d/Listener.d>

Right now it's a struct. (because I didn't want to bother new'ing it) It would have to become a class, and implement the proper SWT listener interface. (maybe as another template argument)

Then it just becomes a matter of adding an instance of the listener to some place in the existing SWT class, and attaching it to SWT's existing listener infrastructure via the usual addXXXXXXListener method.

There are other ways to do it, naturally, but I think this might be best, as it requires almost no alteration of the underlying SWT semantics.  Less thinking is good. :)

 -- andy

In article <bul4fv$2cg1$1@digitaldaemon.com>, Brad Anderson says...
>
>In the code, links to Common Public License 1.0
>
>http://www.eclipse.org/legal/cpl-v10.html
>
>However, we'll be putting this into the public domain.  IANAL, but I would guess that we could give some lip-service to Eclipse, SWT, and IBM in documentation (not source code), and then choose our own license.

Why not just use the Common Public License?  It is very open and acceptable to SourceForge which would be a good place to put this project once it gets rolling.

delegates are actually simply the language feature that replace listeners. see c#.

there is no use in anything else. it's much less typing effort, espencially for the one defining the interface.

btw, Ant, i know dbfkgdfklösdf. i like it. i just hate the name:D

"Georg Wrede" <Georg_member@pathlink.com> schrieb im Newsbeitrag news:bum2da$pp7$1@digitaldaemon.com...
> In article <buls8d$gdi$1@digitaldaemon.com>, Ant says...
> >
> >We should decide on listener(no) versus delegates(yes)
> >from the begining.
>
> Ok, so have I missed the main tradeoffs?
>
>

Georg Wrede wrote:

> In article <buls8d$gdi$1@digitaldaemon.com>, Ant says...
> 
>>We should decide on listener(no) versus delegates(yes)
> 
>>from the begining.
> 
> Ok, so have I missed the main tradeoffs?
> 

I'm not certain of any really notable advantages of using listener interfaces over delegates; SWT uses the former because Java simply does not offer any other way to accomplish the observer pattern.

Listeners are very poorly suited to D primarily one reason: D does not support Java's notion of inner classes.  This means that, to write a handler for any button, one must manually write a class that implements ButtonClickedListener (or whatever), accepts and stores a reference to its parent class, (if it needs it, which is very frequently the case) and responds to the event.

A delegate can just be stuffed inside a collection without regard for the inheritance heirarchy. (sure sounds sloppy when you phrase it like that)  D also supports function literals, which makes it very easy to attach a trivial little handler to a button.

button.onClick ~= delegate(ClickEvent event) { printf("Hello!\n"); };
button.onClick ~= &this.exitApp;

 -- andy

In article <bum409$sbp$1@digitaldaemon.com>, Andy Friesen says...
>
>A delegate can just be stuffed inside a collection without regard for the inheritance heirarchy. (sure sounds sloppy when you phrase it like

:-)

>that)  D also supports function literals, which makes it very easy to attach a trivial little handler to a button.
>
>button.onClick ~= delegate(ClickEvent event) { printf("Hello!\n"); };
>button.onClick ~= &this.exitApp;

Thanks, Dave, Ant, and Andy! This is really cool!

No arguments here.


Mark T wrote:

> In article <bul4fv$2cg1$1@digitaldaemon.com>, Brad Anderson says...
> 
>>In the code, links to Common Public License 1.0
>>
>>http://www.eclipse.org/legal/cpl-v10.html
>>
>>However, we'll be putting this into the public domain.  IANAL, but I would guess that we could give some lip-service to Eclipse, SWT, and IBM in documentation (not source code), and then choose our own license.
> 
> 
> Why not just use the Common Public License?  It is very open and acceptable to
> SourceForge which would be a good place to put this project once it gets
> rolling.
> 
>