Quick inheritance Q

[Duncan]

Hi,

I have a class 'A' that has a virtual member 'm()'. Another class 'B'
inherits from A and overrides m. Yet another class 'C' inherits from B.

A <- B <- C

From C, can I call A's implementation of m(), or the member from the
immediate inheritance from B?

Thanks,
-Duncan

 

[Jeff Johnson]

I have a class 'A' that has a virtual member 'm()'. Another class 'B'
inherits from A and overrides m. Yet another class 'C' inherits from B.

A <- B <- C

From C, can I call A's implementation of m(), or the member from the
immediate inheritance from B?

You can't call A's m() directly from C, no. You can call base.m() from class
B and get A.m(), but there's no base.base.m() syntax you can call from C.
You'd have to build some extra plumbing to allow this to happen. For
example, in B you could have a BaseM() method which could simply call
base.m(). Then in C you'd use BaseM() when you want A's implementation and
just m() when you want B's. (You didn't mention that C overrode m() as well,
so I'm assuming it doesn't.)

 

[Duncan]

Thanks for the info guys. There's an added complication with not having
access to the A and B classes. So extending B to provide access to A
isn't possible.

I'll have a look at what I can do via reflection.

Thanks,
-Duncan

 

[Jeff Johnson]

I'll have a look at what I can do via reflection.

That's easy: anything.

 

[Arne Vajhøj]

That's easy: anything.

There are a few things it can't: make peace in the
middle east etc..



But when it comes to class/object access then there are
not many limits.

Arne

 

[Arne Vajhøj]

I'm sure you can accomplish it using reflection. But as I mentioned
before, it's usually not a good idea to do so. If you need this kind of
functionality, it usually means your design is broken.

My guess would be that >90% of all .NET apps uses reflection
for something, so ...

Arne

 

[J.B. Moreno]

Not using only language features, no. C# only exposes the immediate
base class implementation, through "base".

I agree that it's a bad idea, but


A a = (A) this;
a.m();

or something like it should work...

 

[Jeff Johnson]

There are a few things it can't: make peace in the
middle east etc..

That's because the attitudes on both sides are unmanaged....

 

[Jeff Johnson]

I agree that it's a bad idea, but


A a = (A) this;
a.m();

or something like it should work...

It absolutely will not work. I questioned this myself a while back when I
was just getting into C# and I wrote a simple app to test it. No matter what
you do to the derived class, whether you cast it to the base class or you
create a variable of type base and assign a derived instance to it, when you
call an overridden method you get the DERIVED class's version of the method.
If you need the base class's version you have to add an extra method to the
derived class and explicitly call base.Method() from there.

 

[Duncan]

I'm having trouble finding a working example of what I need.

Assuming I'm in the overridden m() for class C, how can I call A.m()
from there using reflection?

Thanks,
-Duncan

 

[Jeff Johnson]

I'm having trouble finding a working example of what I need.

Assuming I'm in the overridden m() for class C, how can I call A.m() from
there using reflection?

Ohhh, I may have been coming at this from the wrong direction. In my mind I
was envisioning using Reflection to instantiate an A object and call a
protected member on it. You have a C object and want to dig down into its A
ancestor. That might not be possible at all. Sorry if I confused you.

Can you give us a concrete example of what you're trying to do? Real class
and method names, not A/B/C/m. Perhaps we can suggest workarounds.

 

[Duncan]

I'm working out options for extending some MS classes provided with
MSBuild so as to add some new tools. I've no specific problem I'm trying
to overcome yet. But it looks like there's useful functionality from
various levels in a class hierarchy that wouldn't always directly
accessible from classes further up because of layers of overrides.

I'm pretty new to C#, so I initially assumed I could use a similar trick
to C++ to indicate which class's method I wanted and just call it. But
the language has different ideas

-Duncan

 

[Duncan]

I thought that would work too after a bit of Googling. But it
disappointedly still calls C's method.

-Duncan

 

[Arne Vajhøj]

That's because the attitudes on both sides are unmanaged....

Yep.

They need garbage collection.



Arne

 

[Arne Vajhøj]

[...]

I'm sure you can accomplish it using reflection. But as I mentioned
before, it's usually not a good idea to do so. If you need this kind of
functionality, it usually means your design is broken.

My guess would be that >90% of all .NET apps uses reflection
for something, so ...

I doubt that's true. In very large applications it may be difficult to
avoid it completely, but even there the situations are generally rare.
And in smaller desktop programs, utilities, command-line tools, etc.
there's often no need for reflection at all.

Web app with lots of class names in web.config?

App using database via DbProviderFactory.

Serialization.

Web services.

O/R-mappers.

IoC/DI frameworks.

Etc.

However, be that as it may, I wasn't talking about the reflection
aspect. I was talking about the "inherit a class but don't use its
functionality" aspect.

Ah - that I agree with.

Arne

 

[J.B. Moreno]

No, that definitely should not work. The whole point of a virtual
member is so that you always get the polymorphic behavior regardless of
the static (compile-time) type used to access the instance.

You're absolutely right. My mistake.