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

Andrew Fedoniouk wrote:
> 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.
>

Yep, probably this notation will make sense in the future:

delegate interface Contract // 'delegate interface' is a "multidelegate"
declaration
{
   void foo();
   void bar();
}