Quick inheritance Q

  • Thread starter Thread starter Duncan
  • Start date Start date
D

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
 
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?
Click to expand...

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.)
 
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
 
That's easy: anything.
Click to expand...

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
 
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.
Click to expand...

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

Arne
 
Peter Duniho said:
Not using only language features, no. C# only exposes the immediate
base class implementation, through "base".
Click to expand...

I agree that it's a bad idea, but


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

or something like it should work...
 
I agree that it's a bad idea, but


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

or something like it should work...
Click to expand...

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.
 
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
 
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?
Click to expand...

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.
 
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
 
I thought that would work too after a bit of Googling. But it
disappointedly still calls C's method.

-Duncan
 
Arne said:
[...]
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.
Click to expand...

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

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.
Click to expand...

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.
Click to expand...

Ah - that I agree with.

Arne
 
Peter Duniho said:
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.
Click to expand...

You're absolutely right. My mistake.
 
Back
Top