A renewed call for interface methods with bodies

Burton Radons burton-radons at shaw.ca
Thu Jan 24 21:27:07 PST 2008


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.



More information about the Digitalmars-d mailing list