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?

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
>  
>
You are correct that delegates currently don't have the power of 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.