Re: Explicit interface implementation...

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

-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Friday, October 10, 2008 22:57
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Explicit interface implementation...

Hi Gyorgy, yes, as you've guessed you have to implement the interface
explicitly; this is the case whenever there's a conflict between the
interfaces (each other) or an interface and the 'class interface', for
example methods whose signatures only differ on return value. When
implementing an interface explicitly, you have to specify the exact
interface of the method - this is probably because the language supports
derived interfaces providing 'new' methods with conflicting signatures. This
does not affect the abstraction that clients see, e.g.
            IMyInterface ii = new MyClass();
            ii.Item(1); // Invokes IValueIDPair
IMyIterator<IValueIDPair>.Item(int lIndex)
For implementers (that is, the author of MyClass), the language requires
full visibility of the inheritance hierarchy - there is no notion of private
inheritance, so I think you have to expect awareness of IMyIterator<T>.
kevin
(ps. no accessibility modifier is allowed on explicit implementations,
unless you're compiling in outlook ;))

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