A renewed call for interface methods with bodies

Jesse Phillips jessekphillips at gmail.com
Thu Jan 24 23:07:01 PST 2008


On Fri, 25 Jan 2008 00:27:07 -0500, Burton Radons wrote:

> Bill Baxter Wrote:
> 
>> Burton Radons wrote:
>> > Robert Fraser Wrote:
>> > 
>> >> There actually is a language issue: What if a class implements two
>> >> interfaces that both declare the same method, but the class doesn't?
>> >> Which one is called?
>> >>
>> >> BTW, I really need to stop checking this every 10 minutes...
>> > 
>> > This is a problem whether or not the methods are implemented, and
>> > there's a mechanism in place to deal with it that I can't remember as
>> > it's never happened to me.
>> 
>> Yes, but in that case the resolution mechanism doesn't really have to
>> resolve anything.  All the duplicated method pointers in the interfaces
>> all eventually point to the same single implementation in the class
>> that implements the interfaces.
>> 
>> If you allow interfaces to have implementations then I think the
>> compiler will have to enforce that any implemented methods have only
>> one implementor.  Otherwise you've got plain old multiple inheritance
>> and you might as well just get rid of the 'interface' keyword.
> 
> Hm, it seems there IS no conflict resolution:
> 
> 	interface A
> 	{
> 		void foo ();
> 	}
> 	
> 	interface B
> 	{
> 		void foo ();
> 	}
> 	
> 	class C : A, B
> 	{
> 		void foo ()
> 		{
> 			printf ("bar\n");
> 		}
> 	}
> 	
> 	void main ()
> 	{
> 		auto c = new C ();
> 		
> 		c.foo ();
> 		B b = c;
> 		b.foo ();
> 		A a = c;
> 		a.foo ();
> 	}
> 
> This works and just prints "bar\nbar\nbar". I think that's a mistake;
> having the same name doesn't mean they have the same function, and it's
> more likely that the implementor made an error than that he actually
> meant to provide both with the same implementation. I should have to
> write C as:
> 
> 	class C : A, B
> 	{
> 		void A.foo ()
> 		{
> 			printf ("foo\n");
> 		}
> 
> 		void B.foo ()
> 		{
> 			printf ("bar\n");
> 		}
> 	}
> 
> And then when when the object's posing as C call one or the other with:
> 
> 	auto c = new C ();
> 
> 	c.A.foo ();
> 	c.B.foo ();
> 
> The method declaration is the way C# does it; but you need to cast to
> call each method (it would be illegal to call "c.foo" either way, which
> is correct). I don't care either way.
> 
> I don't see what multiple inheritance has to do with this. Nothing about
> what I've suggested modifies the way D should handle function
> overloading at all, and if it does then I would want it to become
> stricter, not loosened.

The problems of multiple inheritance is not related to overloaded 
functions, but overridden functions. Whether that is what you meant or 
not, that is still the problem. Your solution to the interface problem is 
the exact solution that was avoid by not allowing multiple inheritance.

Also, on a side note, c.A.foo() is very unclear, because that suggest 
that A is an object in c with a function foo() that you wish to call, 
which is highly inaccurate because c is an A.



More information about the Digitalmars-d mailing list