June 14, 2004 CONCEPT: Delegates Imply Interface Literals | ||||
---|---|---|---|---|
| ||||
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? |
June 14, 2004 Re: CONCEPT: Delegates Imply Interface Literals | ||||
---|---|---|---|---|
| ||||
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.
|
Copyright © 1999-2021 by the D Language Foundation