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, ...)
     {
         ...
     }
 }


Short answer:  That's how interfaces are defined.

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