As an idea which I personally found very promising.
"Heron interfaces are very different from interfaces as implemented in other
programming languages. The most prominent difference is that they do not
require declarations within a class of intention to implement an interface.
In other words interface implementations are implicit"
http://www.heron-language.com/interfaces.html
Speaking about D - such interfaces can be represented as aggregates of
delegates - one pointer to 'this' and multiple method references.
So they are just next step after delegates - multidelegates if you wish.
Hope somebody will find this useful.
Andrew Fedoniouk.
http://terrainformatuca.com

As an idea which I personally found very promising.
"Heron interfaces are very different from interfaces as implemented in other
programming languages. The most prominent difference is that they do not
require declarations within a class of intention to implement an interface.
In other words interface implementations are implicit"
http://www.heron-language.com/interfaces.html
Speaking about D - such interfaces can be represented as aggregates of
delegates - one pointer to 'this' and multiple method references.
So they are just next step after delegates - multidelegates if you wish.

You are correct. Of course, you can implement them already using
delegates; this adds more space overhead (many copies of the 'this'
pointer) but also gives more flexibility (not all of the 'this' pointers
of all delegates have to be the same). Of course, you don't get a cast
syntax for this, but you can always write a third-party function which
takes a class as an argument and returns a structure of delegates.
I have argued in the past that this thing (what you call multidelegates)
would be a good abstraction, but it's probably a 2.0 feature.

Speaking about D - such interfaces can be represented as aggregates of
delegates - one pointer to 'this' and multiple method references.
So they are just next step after delegates - multidelegates if you wish.

You are correct. Of course, you can implement them already using
delegates; this adds more space overhead (many copies of the 'this'
pointer) but also gives more flexibility (not all of the 'this' pointers
of all delegates have to be the same). Of course, you don't get a cast
syntax for this, but you can always write a third-party function which
takes a class as an argument and returns a structure of delegates.
I have argued in the past that this thing (what you call multidelegates)
would be a good abstraction, but it's probably a 2.0 feature.