www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CONCEPT: Delegates Imply Interface Literals

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
D's delegates are a generalization of C++'s class architecture (or of 
Java's interfaces).

Java:

interface Foo {
   int CallbackFunction(char,float,Object);
}
class Bar implements Foo {
   int CallbackFunction(char a,float b,Object c) { ... }
}
Foo f = new Bar;
f.CallbackFunction('a',0.0,null);



D makes this simpler:

class Bar {
   int Whatever(char a,float b,Object c) { ... }
}
Bar b = new Bar;
int delegate(char,float,Object) f = b.Whatever;
f('a',0.0,null);



So, as I pondered this, I realized that a delegate was, more or less, an 
interface that had only one member function.  I asked myself, then, why 
you shouldn't have delegates with multiple member functions?  Or, 
perhaps, interface literals?  I don't yet have a syntax that I like, but 
I'll throw out a couple of trial balloons.



What if you could do something like this:

interface Baz {
   int a();
   void b(char);
   Object c();
}
void Func() {
   Baz b = interface Baz {
     a: int delegate() { ... }
     b: void delegate(char arg) { ... }
     c: Object delegate() { ... }
   }

   CallOtherFunc(b);
}



Or perhaps this:

void Func() {
   Baz b = new Baz;
   b.a = int delegate() { ... }
   b.b = void delegate(char arg) { ... }
   b.c = Object delegate() { ... }

   CallOtherFunc(b);
}



Or perhaps this:

void Func() {
   compound-delegate {
     int a();
     void b(char);
     Object c();
   } del = compound-delegate {
     a: int delegate() { ... }
     b: void delegate(char arg) { ... }
     c: Object delegate() { ... }
   }

   CallOtherFunc(del);
}



Thoughts?
Jun 14 2004
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I'm copying my reply back to the list.  I'm answering everything at the 
bottom, so that people can see your whole post intact.

Bent Rasmussen wrote:

D's delegates are a generalization of C++'s class architecture (or of
Java's interfaces).
    

I don't see that. A delegate merely a way to point to a (environment,function). In effect a closure. Of course a delegate can be passed around instead of an object and that may be nice in some situations, but they aren't that powerful because you can't construct delegates to nested functions that work using the environment. int delegate() test(int v) { int x = v; int f() { return x; } return &f; // no can do (x is broken) } So plain objects are more powerful there because you can construct them and their member functions work with "this" while you cannot construct a function on the fly where the environment is created in a function. That's childs play in ECMAScript/DMDScript (and its very useful) function test(x) { var x = x return function() { return x } } If memory serves me you can construct anonymous classes in Java but to my knowledge they wohn't remember any local variables of the function that created them. That's my understanding at least, but I'm open to be surprised. Regards, Bent Rasmussen

classes, because they can't carry member data. This is why I have suggested that D should include the ability to copy stack delegates. (See my post, "HACK: Function to copy stack delegates", which I posted on 6/10.) If you can copy a stack delegate, then you have essentially created an anonymous class, the member variables of which are the local variables and arguments of that stack frame.
Jun 14 2004