Feature Request: Hiding a property/method in a subclass

[Jeroen Smits]

To Microsoft or other people who are interested, I have a feature request:

I would really like to have an option to 'hide' a property or method from an
inherited class. For example when I create a subclass and supply a default
value for a property. Currently I create a new property, using the new
keyword, and only supply the get accessor witch will always return the
predefined value. But I would really like to be able to hide it completly.

Currently I do something like this:

class NameOfClass : NameOfBaseClass
{
NameOfClass()
{
base.PropertyName = PropertyName;
}

public new bool PropertyName
{
get
{
// return the default value
return true;
}
// no set method, we don't want it to change.
}
}

But I would realy like to be able to hide the property totally, because it
isn't needed anymore for my custom implementation of the new class/component
Something like:

class NameOfClass : NameOfBaseClass
{
NameOfClass()
{
base.PropertyName = true;
}

hide bool PropertyName;
}

Where the 'hide' keyword (or a 'remove' or 'delete' keyword, whatever)
whould hide the implementation of the base class.
Ofcourse this keyword would work somewhat similar as the 'new' keyword on a
method or property where the base class or code that uses the baseclasses
type, would still see the old implementation.

Is this a good idea, or am I missing some logic why this wouldn't be
possible or maybe a bad thing to implement?

 

[Frank Oquendo]

Is this a good idea, or am I missing some logic why this wouldn't be
possible or maybe a bad thing to implement?

Why not just mark the base implmentation as private?

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[Jeroen Smits]

Why not just mark the base implmentation as private?

If I had control over the base class, ofcourse. But what if you want to
create - for example - a new class based on the
System.Windows.Forms.ListView class or some other control you have no
control over.

I do this a lot, make a subclass on a existing class and supply all kind of
default behaviors and settings. I think hiding properties and or method that
are not supported anymore for the new derived class would be a cleaner
sollution as throwing a NotSupportedException or something like that.

 

[Jon Skeet [C# MVP]]

I would really like to have an option to 'hide' a property or method from an
inherited class.

That would break Liskov's Substitutability Principle, and is a
generally bad thing, IMO. The user would always be able to get round it
by casting to the base type anyway.

 

[Alvin Bruney]

and Liskov's Substitutability Principle is????

 

[Jon Skeet [C# MVP]]

and Liskov's Substitutability Principle is????

A quick web search will answer that much more fully than I'm prepared
to here, but in a few words it is: "You should always be able to treat
instances of a derived class as if they were instances of the base
class."

 

[Jeroen Smits]

A quick web search will answer that much more fully than I'm prepared
to here, but in a few words it is: "You should always be able to treat
instances of a derived class as if they were instances of the base
class."

Well then C# already breaks it. If create a subclass and use the 'new'
keyword to redefine a property which had a get/set accessor, to only have a
get accessor, the set accessor gets hidden. I just would like to extend this
possibilty to hide alle accessors (or methods).

Ofcouse one can get around by casting to the base class, but thats not my
point. I just think hide methods can give a clearer implementation of a
class by hiding any methods that will throw NotImplemented exceptions
anyway. And by letting it work in much the same way as the 'new' keyword
code that is using the some baseimplementation won't get broken by it.

 

[Jon Skeet [C# MVP]]

Well then C# already breaks it. If create a subclass and use the 'new'
keyword to redefine a property which had a get/set accessor, to only have a
get accessor, the set accessor gets hidden.

Yes - something I also don't like, along with explicit interface
implementation.

I just would like to extend this
possibilty to hide alle accessors (or methods).

Ofcouse one can get around by casting to the base class, but thats not my
point. I just think hide methods can give a clearer implementation of a
class by hiding any methods that will throw NotImplemented exceptions
anyway. And by letting it work in much the same way as the 'new' keyword
code that is using the some baseimplementation won't get broken by it.

Hiding methods is always a bad idea to start with though - the reason
it's available (IMO) is to prevent accidental overloading and allow you
to get away with situations which have unfortunately cropped up due to
the base class getting new methods which happen to have the same
signature as the derived class's methods. Using "new" you can get
backwards compatibility, but it will always be unfortunate - it's
certainly not something you should be regularly doing deliberately, and
not something to be encouraged by extending it to other areas.

 

[Jeroen Smits]

Yes - something I also don't like, along with explicit interface
implementation.


Hiding methods is always a bad idea to start with though - the reason
it's available (IMO) is to prevent accidental overloading and allow
you to get away with situations which have unfortunately cropped up
due to the base class getting new methods which happen to have the
same signature as the derived class's methods. Using "new" you can get
backwards compatibility, but it will always be unfortunate - it's
certainly not something you should be regularly doing deliberately,
and not something to be encouraged by extending it to other areas.

Well if they add it or not, for now I'll have to stick with the 'new'
keyword and using the EditorBrowsableAttribute. This way it will at least be
hidden while coding