Has any consideration been given to delegates?

The way I see it is that there are diffrent degrees that objects know about each other :

1st degree is that the objects know about each other the most, they know the exact type and they know how to communicate with each other.

2nd degree is that the objects only know the inherited type or interface, they dont know that much information about each other.

3rd degree is that objects dont know about each other but learn about each other through runtime type information.

4th degree is that objects dont know about each other and a third party object is used to help link them together.

From what I have read, D supports 1 2 & 3 quite well, and while 4 is possible things like delegates would help make them easier.

The 4th degree is usefull for creating constructor sets, or independant components that a constructor-object can use to construct a program from components. It is usually used in C GUI APIs (like GTK+) for event handling (mostly because things are less structured and more controllable) but its common in C++ GUI APIs to use interfaces as event handlers, and self constructing objects (objects that inherit from other objects to connect themselves).

A good example of this is to create a button that quits an application...

Typically in C++ event handling, you will find that in order to quit an application, you must have an object that inherits from an event handling class or interface, with in the even handling function you must find out what the event is and find out if it is the button release event for your quit button, if it is found to be that event you would then call the application/system quit function.

The other way to do this, is to map the application/system quit function to the button release event. So when the button object has a mouse button release event while the mouse is in its area, it calls any event handler hooked into it, which the hooked event handler is a delegate that calls the quit function.

This allows for some interesting possibilities for runtime application developement, where you can create and hook component/objects into each other to form applications. This also allows users to go in and tweak applications by adding additional components or altering components (adding things to the interface), or third party update (reconstruction) utilities that can do it for them.

(Note - what I describe is a bit more robust then the C# delegates, in that it allows function-mapping/reparameterization.)

D doesn't have delegates for the dumb reason that I just don't understand them. -Walter

interested wrote in message <9lh7ih$2s5g$1@digitaldaemon.com>...
>Has any consideration been given to delegates?
>
>The way I see it is that there are diffrent degrees that objects know about each other :
>
>1st degree is that the objects know about each other the most, they know
the
>exact type and they know how to communicate with each other.
>
>2nd degree is that the objects only know the inherited type or interface, they dont know that much information about each other.
>
>3rd degree is that objects dont know about each other but learn about each other through runtime type information.
>
>4th degree is that objects dont know about each other and a third party object is used to help link them together.
>
>From what I have read, D supports 1 2 & 3 quite well, and while 4 is possible things like delegates would help make them easier.
>
>The 4th degree is usefull for creating constructor sets, or independant components that a constructor-object can use to construct a program from components. It is usually used in C GUI APIs (like GTK+) for event handling (mostly because things are less structured and more controllable) but its common in C++ GUI APIs to use interfaces as event handlers, and self constructing objects (objects that inherit from other objects to connect themselves).
>
>A good example of this is to create a button that quits an application...
>
>Typically in C++ event handling, you will find that in order to quit an application, you must have an object that inherits from an event handling class or interface, with in the even handling function you must find out what the event is and find out if it is the button release event for your quit button, if it is found to be that event you would then call the application/system quit function.
>
>The other way to do this, is to map the application/system quit function to the button release event. So when the button object has a mouse button release event while the mouse is in its area, it calls any event handler hooked into it, which the hooked event handler is a delegate that calls the quit function.
>
>This allows for some interesting possibilities for runtime application developement, where you can create and hook component/objects into each other to form applications. This also allows users to go in and tweak applications by adding additional components or altering components (adding things to the interface), or third party update (reconstruction) utilities that can do it for them.
>
>(Note - what I describe is a bit more robust then the C# delegates, in that it allows function-mapping/reparameterization.)
>
>
>

Walter <walter@digitalmars.com> wrote in message news:9lml51$10vj$4@digitaldaemon.com...
> D doesn't have delegates for the dumb reason that I just don't understand them. -Walter
>

This is probably a good example of what Delegates would be like in C++...

________________________________

#include <stdio.h>

class EventGenerator;
class EventMonitor;
void EventFunction(EventMonitor *em);

struct Delegate{
    void *reciever;
    void (*caller)(void *);
};

class EventGenerator{
public :
 Delegate *delegate;
public :
 void process(){
        /*code here to decide to send an event*/
        delegate->caller(delegate->reciever); // send event
    }
};

class EventMonitor{
public :
 void EventHandler(){
        printf("recieved event\n\n");
    }
};

void EventFunction(EventMonitor *em){
    em->EventHandler();
}

void main(){

 EventGenerator *gen = new EventGenerator;
 EventMonitor *mon = new EventMonitor;
 Delegate *del = new Delegate;

 del->reciever = (void*)mon;
 del->caller = (void(*)(void*))EventFunction;

 gen->delegate = del;
 gen->process();

 delete gen;
 delete mon;
}

________________________________


As you can see, EventMonitor doesnt have to inherint from any classes (or in other cases implement any interfaces) for event handling, it isnt even aware of the Event Generator class (that it even exists).

The EventGenerator class is also the same, it has no idea what it is calling, it could call any function of any class (well in C# its limited to calling any function with the correct number of parameters).

Basicly this is allowing Object Oriented programming to do something that C could do easily, and that is pass call backs and event handlers (individual functions), except now do them from objects.

This also shrinks the needs for interfaces to a degree, and allows you to do things that were not intended. You could for example, hook objects together on a function call basis, rather then build objects that know about each others interfaces. Objects can be completely oblivious to each others purpose actions and structure, integrating libraries would be more seamless for libraries that support delegates.

In C# deleages are made easier then the C++ code above, all the extra coding work that is done, is made much simpler. Plus C# also supports delegate lists, so that it can call multiple functions from one or more objects. This is where I learned about delegates for C#...

http://www.codeproject.com/csharp/delegates-part1.asp