From this and the above examples, I'm sold on delegates instead of rote copying of listeners already in SWT.  This falls into the category of taking advantage of a feature in D that isn't in Java.  Hopefully a bunch of you will be available to assist.

Andy Friesen wrote:

> 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 <bumbl7$17ft$3@digitaldaemon.com>, Brad Anderson says...
>
> From this and the above examples, I'm sold on delegates instead of rote copying
>of listeners already in SWT.  This falls into the category of taking advantage of a feature in D that isn't in Java.  Hopefully a bunch of you will be available to assist.
>

The thing I don't like on the SWT project is that the way to
make to linux is through GTK.
Been there, done that...

:(

well, maybe the SWT has some excelente ideas on how to do it... might be interesting to learn how SWT APIs are converted to GTK calls...

Ant

> The thing I don't like on the SWT project is that the way to make to linux
> is through GTK.
> Been there, done that...
> 
> :(
> 
> well, maybe the SWT has some excelente ideas on how to do it... might be interesting to learn how SWT APIs are converted to GTK calls...
> 
> Ant

It shouldn't be as hard or as bad, since the SWT has the internal.gtk type calls already mapped out.  At least we know what will be used.  We can use that section of the java source to map out a D gtk module with extern(C) calls (similar to how you did it in DUI). From there we just need to make calls similar to the java OS.foo calls.  Of course, it's easy to talk about it. :)  As a first project, I guess I could try making a gtk module based on the JNI.  I can use DUI as a guidline :).  The harder part may be the whole modification process of changing from listeners to delegates.  I don't know how that will go.

Later,

John

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

Thanks for this. I've studied it and it looks quite promising. As you say, it is quite nifty :-).  That's an interesting use of associative arrays you've got in there. Just have to change the "instance" keyword to the "!" symbol, I think.

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

We should be able to do that.

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

OK

> 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

It's a great start.  Thanks!

John

John Reimer wrote:
> Thanks for this. I've studied it and it looks quite promising. As you
> say, it is quite nifty :-).  That's an interesting use of associative
> arrays you've got in there. Just have to change the "instance" keyword to
> the "!" symbol, I think.

Whoops.  I've updated it with the newest version.  (I use that template in a bunch of places.  It's only a matter of time before they start to fall out of sync)

 -- andy

"Brad Anderson" <brad@sankaty.dot.com> wrote in message
news:bul1v1$281v$1@digitaldaemon.com...
| ...
|   I can, however, set up a forum using phpBB on a public site.
|
| Brad
|

If you wish, you can send me a line and I'll a category for it in
http://s3.invisionfree.com/ln5yrestgv/index.php.
And if anyone is interested, I haven't made any progress in Delphi4D due to
(guess, guess) lack of time. I hope I can get back to it soon.
Although I remember Walter saying he didn't like the need to distribute an
application with a dll. Delphi4D apps will work like that. Should I keep it
on? Mmm, time for a poll. You know where to vote ;).

-----------------------
Carlos Santander Bernal

"Brad Anderson" <brad@sankaty.dot.com> wrote in message news:bul4fv$2cg1$1@digitaldaemon.com...
> 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.

The license does not allow it to be placed into the public domain. However, the license does appear to be compatible with our purposes, and I don't see any problems with it.

"Andy Friesen" <andy@ikagames.com> wrote in message news:bum409$sbp$1@digitaldaemon.com...
> 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;

That's why D doesn't do inner classes - delegates are a much nicer solution for the same problem.

Andy Friesen wrote:
> Listeners are very poorly suited to D primarily one reason: D does not support Java's notion of inner classes.

That leads me to an idea: if we would write an automatic Java->D converter, running over an inner class could automatically convert it into a delegates, no?

-eye

any update?