Inheritence Question

[bpayne111]

Is there be a way to Remove a method from a class that inherits from another?

 

 

i seriously doubt it but figured i'd ask just in case

[joteke]

Shadowing might be near what you are looking for although it does not actually remove the inherited type members.

 

"A derived type shadows the name of an inherited type member by redeclaring it. Shadowing a name does not remove the inherited type members with that name; it merely makes all of the inherited type members with that name unavailable in the derived class. The shadowing declaration may be any type of entity.

 

"

[quwiltw]

Having this problem is usually a good indicator that you might be using inheritance when another approach like just having it contain a property of that type might be more appropriate. Just a thought.

[bpayne111]

i was just curious

i have a property in an interface that i really don't need in reality, i just got rid of the declaration in the interface... but that sitution just kind of spawned a series of thoughts, that made me wonder

 

thanks guys

[Heiko]

Err. Come to think of it, of course you can hide a method or property:

 

Public Mustinherit Class AbstractEventArgs 
   Inherits EventArgs

#Region "Konstruktoren"
   Protected Sub New(ByVal Context As ourSpeciaEnum)
       mSpecial = Context
   End Sub
#End Region

#Region "Membervariablen"
   Private mSpecial As ourSpeciaEnum
#End Region

#Region "Properties"
   Public ReadOnly Property Context() As OurSpecialEnum
       Get
           Return mContext
       End Get
   End Property
#End Region
End Class

 

And then set the original private:

 

Public Class ViewerClosedEventArgs
   Inherits AbstractEventArgs

   Private Sub New()
       'never called
       MyBase.New(enumUnknown)
   End Sub

   Public Sub New(ByVal Context As ourSpeciaEnum)
       MyBase.New(Context)
   End Sub

'more properties here ....

End Class

 

Ok, we are just hiding a signature here, but I am sure it will work with methods, too.

[quwiltw]

I don't get it Heiko, what's this demonstrating? I don't see as where you explicitly hiding anything in the base class from the inherited class. Am I missing something?

[Heiko]

Someone instantiating a ViewerClosedEventArgs can not use

New() but must use New(Context) instead.

 

New() is hidden.

[bpayne111]

i see what you are getting at... but it looks like you did it kinda wrong. you didn't actually hide anything there was never a Sub New() to begin with. I think Overriding and changing it to Private would be the way to do it...

[Heiko]

There's a Sub New in the EventArgs, from which my abstract class "AbstractEventArgs" inherits. Should have mentioned that I suppose :)

[quwiltw]

I think constructors are different entirely. A constructor is unique to that class so it isn't as though you're hiding the constructor of the base class, you're hiding the default constructor of the derived class. I'd need to read up on this to use the right terminology maybe. I don't think you're example would work with a regular method or property as you'd have to use Shadows but that won't truly hide it. Maybe I'm wrong?

[quwiltw]

There's a Sub New in the EventArgs, from which my abstract class "AbstractEventArgs" inherits. Should have mentioned that I suppose :)

 

And that still fires no matter what you're base class is doing. Again, constructors are unique to the current class. They are kinda "not-inherited" in a sense.

[Heiko]

Now *I* don't get it :)

 

First you say the New() of the base classes base class still fires, and then you say constructors are unique to the current class.

 

Well.

However, back to the original discussion, I think this is a way to hiding methods in inherited classes. Someone's gotta try it, though.

[quwiltw]

Doesn't work. Like I said, since regular methods are inherited, you'd either have to override (can't because of the difference in scope) or Shadow(which doesn't seem to work either).

 

What don't you get? what you said is true. The base class's New() will always get called AND a constructors aren't inherited (ie. are unique to the class). Maybe it's my wording here. I'd have to check a book to make sure I'm saying it right, but what I'm meaning is true;)

[Heiko]

;)

 

Yep. Tried it myself too (not that I didn't believe you).

Won't work.

Tough luck.

Lotsa replies though :)

[bpayne111]

off subject but here it goes

when will we see dual inheritence?

 

I was thinking that maybe interfaces should be allowed to have shared members to allow for a sort of dual inheritence

ie. a property on an interface that would be the same for all implementations.

 

NOTE: if you read the original subject title i guess i am on subject lol

 

does anyone know if microsoft is wokring on developing something to mimic dual inheritence?

 

just keeping the thread alive :)

[quwiltw]

If I'm reading your post correctly, you're talking about Multiple Inheritance. C++ is the only language that I know that supports it. I doubt it'll ever come to the other .NET languages because it's a pretty contentious capability. I could be wrong though.

[bpayne111]

yes i guess that would be the better term.

what about C#? and what do you mean by contentious?

[quwiltw]

I doubt it'll ever be in C# either, but again, my crystal ball is probably about as good as anyones. By contentious, I meant that people usually either love it or hate it. The dependency's in a poorly designed system with multiple inheritance can get confusing.

 

As far as the love it or hate it, take a project with multiple inheritance: those developers who originally designed/implemented it will love it and those who have to come in a year or two later to maintain/tweak it will generally hate it.