• Russ Lewis (59/59) Jun 14 2004 D's delegates are a generalization of C++'s class architecture (or of
• Russ Lewis (11/44) Jun 14 2004 I'm copying my reply back to the list. I'm answering everything at the

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?

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
  

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.