www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - interfaces

reply marko <tm030127d galeb.etf.bg.ac.yu> writes:
Why are function definitions forbidden in interfaces?

interface OutputStream
{
	void write(byte[] buf);
	void writef(char[][] format, ...)
	{
		...
	}
}
Oct 13 2004
next sibling parent reply Sjoerd van Leent <svanleent wanadoo.nl> writes:
marko wrote:
 Why are function definitions forbidden in interfaces?
 
 interface OutputStream
 {
     void write(byte[] buf);
     void writef(char[][] format, ...)
     {
         ...
     }
 }

Simple answer: They are interfaces Complex answer: Lessons Learned. Multiple inheritance is more or less a pain to integrate into a language. Not only that, but it makes development also much more painful. If you really want to have functionality from something like that, try to use a mixin or abstract adapter class. Regards, Sjoerd
Oct 13 2004
parent reply Burton Radons <burton-radons smocky.com> writes:
Sjoerd van Leent wrote:

 marko wrote:
 
 Why are function definitions forbidden in interfaces?

 interface OutputStream
 {
     void write(byte[] buf);
     void writef(char[][] format, ...)
     {
         ...
     }
 }

Simple answer: They are interfaces Complex answer: Lessons Learned. Multiple inheritance is more or less a pain to integrate into a language. Not only that, but it makes development also much more painful.

This doesn't have anything to do with MI - an interface method would have to be built on the abstract methods within the interface, so the compiler would merely have to insert a cast to the interface for "this" at the start of the method. Providing default implementations makes sense; without them, we have interfaces with either a paucity of functionality or a surfeit of methods with only one possible implementation. With them, we can simplify the task for implementors (reducing potential for incorrect implementations) and have interfaces which are actually useful out-of-the-box (why use DOM when a self-written node structure will have such an obvious function as nestedFindByAttributeValue?.) There should also be support for "final" to prevent the method from being inserted into the vtable as well.
 If you really want to have functionality from something like that, try 
 to use a mixin or abstract adapter class.

Mixins are neither type- nor documentation- nor maintenance-safe.
Oct 14 2004
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Burton Radons wrote:
 Sjoerd van Leent wrote:
 Lessons Learned. Multiple inheritance is more or less a pain to 
 integrate into a language. Not only that, but it makes development 
 also much more painful.

This doesn't have anything to do with MI - an interface method would have to be built on the abstract methods within the interface, so the compiler would merely have to insert a cast to the interface for "this" at the start of the method. Providing default implementations makes sense; without them, we have interfaces with either a paucity of functionality or a surfeit of methods with only one possible implementation. With them, we can simplify the task for implementors (reducing potential for incorrect implementations) and have interfaces which are actually useful out-of-the-box (why use DOM when a self-written node structure will have such an obvious function as nestedFindByAttributeValue?.)

Ok, I know that you, Burton, knock mixins later in this very post, but your post got me thinking :) Couldn't an interface (or something like it) declaration function to declare both an interface AND a mixin? When you have a class derive from that interface-type-thingy, then you both get the interface AND the mixin is mixed into the class. That is, this code: interface-thingy FooInt(T) { void foo(T arg) { writef("FooInt.foo(): default\n"); } } class Foo : FooInt(char[]) {} would be equivalent to this code: interface FooInt_Int(T) { void foo(T); } template(T) FooInt_Mixin { void foo(T arg) { writef("FooInt.foo(): default\n"); } } class Foo : FooInt_Int(char[]) { mixin FooInt_Mixin(char[]); } This gives us the default-implementation power that we desire for interfaces without the MI troubles. Interestingly, using this mechanism, it is also possible for the deriving class to override method implementations; since the interface's implementations are part of a mixin, they can be superceded by the literal implementations!
Oct 15 2004
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
marko wrote:
 Why are function definitions forbidden in interfaces?
 
 interface OutputStream
 {
     void write(byte[] buf);
     void writef(char[][] format, ...)
     {
         ...
     }
 }

Longer answer: To make it easier for implementations to allow redefinition. Of all compiled languages, only Eiffel did a good job of implementing multiple inheritance. (And even there they've been adding new restrictions recently.) Usually interfaces combined with delegation will suffice to easily handle the job that multiple inheritance attempts to solve. So it probably isn't worth the effort required to do a good job with multiple inheritance. Long answer: Sorry, I'm not qualified to answer. Ask Walter.
Oct 14 2004