www.digitalmars.com         C & C++   DMDScript  

D - Delegates...

reply "interested" <here nowhere.net> writes:
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.


it allows function-mapping/reparameterization.)
Aug 16 2001
parent reply "Walter" <walter digitalmars.com> writes:
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.


it allows function-mapping/reparameterization.)
Aug 18 2001
parent "interested" <here nowhere.net> writes:
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 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.



lists, so that it can call multiple functions from one or more objects. This


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