A renewed call for interface methods with bodies

[Robert Fraser]

Burton Radons wrote:
> I'd like to remind everyone about this lacking feature, why it's important, and how the lack of it negatively impacts interface use. It's important for two tasks: when you're writing an interface, and when you're using an interface from someone else (through COM/CORBA/etc).
> 
> When it's your own interface, method bodies allow you to provide for default implementations when the method can be implemented in terms of the abstract interface. This can be vital if your interface has hundreds of methods. While you can write a "base" implementation of the interface for others to inherit from, it can be very confusing to convey to the implementor what methods are not supported, requiring careful maintenance.
> 
> Because of this lack in various interface-using languages, interfaces tend to have a limited number of methods. So when you use, for example, HTML's DOM, you have insertBefore but not insertAfter. Without interface methods with bodies (which aren't inserted into the vtable and would therefore be declared "final"), you're stuck using a limited interface. That's not to mention that sometimes interfaces have methods that would work beautifully with operator overloading, but you can't use them in that way because you don't want to rename the method or because it requires a slight tweak.
> 
> The only way to extend interfaces you don't own is through functions, and function overloading beyond aliases for the same operation is inadvisable in general and specifically denied by D's construction. So your only real option is to use a naming system like "Node_insertAfter", leading to two completely different ways to use the interface, attaching a redundant bit of notation to the function name (and hoo boy is that a mouthful with many DirectX interfaces), splitting the documentation, and disorganising the source file. This is particularly bad with COM, which has an incompatible calling method that requires wrapping every interface method in order to be safe.
> 
> Either way it's sloppy and inelegant, and it's not at all appropriate for a modern language to look this shabby when doing something so basic. So we need interface methods in two ways. One when you own the interface, and one where you don't:
> 
> interface Foo
> {
> 	int bar ();
> 
> 	// Inserts it into the vtable, allowing it to be overloaded.
> 	int baz ()
> 	{
> 		return bar + bar;
> 	}
> 
> 	// Not inserted into the vtable.
> 	final int boo ()
> 	{
> 		return baz * baz;
> 	}
> }
> 

Many of D interfaces have a reference implementation as a mixin:

interface IFoo
{
     void bar();

     template Impl()
     {
         void bar()
         {
             // Do stuff
         }
     }
}

class Baz : IFoo
{
     mixin IFoo.Impl!();
}

It provides a standard, safe implementation that classes can choose to 
use or not, and allows safe multiple-inheritance like behavior.