Re: Explicit interface implementation...

MyClass doesn't hide members of interfaces derived by IMyInterface.  It would hide members of derived interfaces of a derived class, not an interface.

What you're seeing is not hiding of members, it's the clause in the spec: "For an explicit interface member implementation to be valid, the class or struct must name an interface in its base class list that contains a member whose fully qualified name, type, and parameter types exactly match those of the explicit interface member implementation. "  And, in fact, the spec details an almost identical case to yours right after that statement.

A class mplementing an interface that "derives" from another interface doesn't mean the class "inherits" the methods of the "derived" interfaces, it means the class implements those interfaces.  Interface derivation likes this just means implementors must implement members of those derived interrfaces.  So, in effect, it's as if you declared MyClass like this:

public class MyClass : IMyInterface, IMyIterator<IValuePair>
{
/....
}

So, remembering the clause I quoted, to explicitly implement the Item member you would have to do this:

	IValuePair IMyIterator<IValuePair>.Item ( int lIndex )
	{
		return ( null );
	}

Cheers -- Peter

On Fri, 10 Oct 2008 23:32:18 -0500, Gyorgy Bozoki <[email protected]> wrote:

>Kevin,
>
>Thank you for your reply. At first I thought you might be right about
>derived interfaces hiding base methods and providing conflicting ones
>through 'new', but after more thinking, I still don't understand why I have
>to use the exact interface that provides the method, instead of the most
>derived interface. If my most derived interface replaces a method with new,
>I'd want to implement that method anyway, not the base version - since the
>derived interface replaced it with a different method signature. This seems
>funny to me; I cannot think of a reason why it should be this way. (But then
>I don't know the entire C# specs by heart, so no wonder. :)  )
>
>I didn't try your example to see if class clients can use the derived
>interface - I ended up changing the method names in IMyIterator<> so that
>they don't clash and I don't need the explicit implementation anymore. It's
>less than ideal, but I don't want to use generic interfaces in my
>business/client code (IMyInterface is easier to read/remember than
>IMyIterator<IValueIDPair> ) I normally create generic interfaces and then
>derive mostly empty specific ones. (For example IPair<T1, T2> ->
>IIntStringPair : IPair<int, string> )
>
>And yes, it was the Outlook compiler that missed those public-s in my
>original mail. :)  I swear Outlook 2003 used to catch those problems, but
>they changed something in 2007. ;)
>
>Thanks again,
>Gyorgy Bozoki

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives