Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / CLR / May 2006

Tip: Looking for answers? Try searching our database.

Reflection on Interfaces and inherited members

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Niall - 03 May 2006 12:13 GMT
I'm having some troubles with unit tests that use mocks of interface types.
I'm mocking an interface type that inherits some members. The mock framework
attempts to verify the method I'm trying to mock is on the type it's mocking
and fails. The framework is not using any binding flags to identify members
from the declaring type only.

The reason it fails is that members on interfaces inherited from another
interface don't seem to be returned from the reflection methods. This is not
the case for inherited members in classes.

Is this the by design behavour for reflection on interfaces?

Niall
Jon Shemitz - 03 May 2006 19:02 GMT
> The reason it fails is that members on interfaces inherited from another
> interface don't seem to be returned from the reflection methods. This is not
> the case for inherited members in classes.
>
> Is this the by design behavour for reflection on interfaces?

Without code, I'm not sure exactly what behavior you're describing ...
but probably. For example,

 interface IBase { void Foo(); }
 interface IDerived: IBase {}

 class Implements: IDerived
 {
   void IBase.Foo() {} // can't be IDerived.Foo
 }
 

Signature

<http://www.midnightbeach.com>     Contracting, consulting, training
.NET 2.0 for Delphi Programmers  <http://www.midnightbeach.com/.net>
                                  In production - in stores by June

Niall - 04 May 2006 17:33 GMT
I'm referring specifically to how the reflection API methods (ie GetMethod,
GetProperty, etc) treat inherited members in interfaces as opposed to
inherited members in classes.

Run the following code. GetMethod finds the inherited method in the derived
class, but not in the derived interface. I realise that you can dig up the
hierachy with reflection to find the inherited members, but the code
performing the reflection is in a third party library we are using.

I suspect this is somehow the by design behaviour rather than a bug. But I'm
trying to understand the reason why the behaviour should differ between
interfaces and classes in this way.

Niall

using System;
using System.Reflection;

namespace ReflectionTest
{
    class Program
    {
        static void Main(string[] args)
        {
            MethodInfo iMi = typeof(IChild).GetMethod("DoParent", BindingFlags.Public
| BindingFlags.Instance);
            MethodInfo mi = typeof(Child).GetMethod("DoParent", BindingFlags.Public |
BindingFlags.Instance);

            Console.WriteLine("Interface method: " + ((iMi == null) ? "null" : "not
null"));
            Console.WriteLine("Class method:     " + ((mi == null) ? "null" : "not
null"));

            Console.ReadLine();
        }
    }

    public interface IParent
    {
        void DoParent();
    }

    public interface IChild : IParent
    {
        void DoChild();
    }

    public class Parent : IParent
    {
        public void DoParent()
        {
        }
    }

    public class Child : Parent, IChild
    {
        public void DoChild()
        {
        }
    }
}

> > The reason it fails is that members on interfaces inherited from another
> > interface don't seem to be returned from the reflection methods. This is not
[quoted text clipped - 13 lines]
>   }
>  
Jon Shemitz - 04 May 2006 18:24 GMT
> I suspect this is somehow the by design behaviour rather than a bug. But I'm
> trying to understand the reason why the behaviour should differ between
> interfaces and classes in this way.

As per my previous message, I suspect it has to do with the nature of
interface inheritance. A derived interface doesn't act like a flat set
of methods and properties; it acts like a collection of methods and
properties and interfaces. You can see this in the implementation
behavior (where you have to implement IBase.Foo, not IDerived.Foo) and
you're seeing this in Reflection.

Why? I don't really know - but I guess it's at least partly
implementation driven. Each interface is its own vtable and possibly
(as in, I haven't looked, and [sorry!] don't have the time to look
this morning) ancestral interfaces are implemented as pointers to the
ancestral vtable, not as spaces within the derived vtable. This would
save space, ay some slight runtime cost.

Signature

<http://www.midnightbeach.com>     Contracting, consulting, training
.NET 2.0 for Delphi Programmers  <http://www.midnightbeach.com/.net>
                                  In production - in stores by June

Ben Voigt - 04 May 2006 19:11 GMT
> I'm referring specifically to how the reflection API methods (ie
> GetMethod,
> GetProperty, etc) treat inherited members in interfaces as opposed to
> inherited members in classes.

I think because if you want the implementing method, you use
GetInterfaceMap.

> Run the following code. GetMethod finds the inherited method in the
> derived
[quoted text clipped - 75 lines]
>>     void IBase.Foo() {} // can't be IDerived.Foo
>>   }

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.