I'm afraid real work is rearing its ugly head and time is scarce.  We've made some progress, and I'll have more time next week, but it's slow going.  We'll post when we have something.

Cheers,
Brad


Mark T wrote:
> any update?
> 
> 

On Thu, 22 Jan 2004 10:08:13 -0800, Walter wrote:

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

What! that's not a valid reason.
Inner classes solve other problems.

How difficult are they to implement?
(In my ignorance) you just a need a pointer to the outer
class it's very simple to do...

please add them before 1.0

for instance they are useful to build GUIs.

leds file browser contains a nested class to hold the
file tree - it would benefit from the nested class being inner,
nothing to do with events.
leds project browser (some thing)...

leds addToProject functions (not released yet)
contain nested classes create the user interfaces - they
would benefit if we have inner classes.

In all these 3 examples I have to pass extra parameters
to the nested classes ctors to have access to the outer
class members.

Ant