Hiding a base function so it is not accessible

[Mike]

According to the MSDN (see reference below), it is possible to change
a base class function from public to private. How is this done? I've
tried using "new", but the function is still accessible.

From MSDN:
"A derived type can hide an inherited member by defining a new member
with the same signature. This might be done to make a previously
public member private or to define new behavior for an inherited
method that is marked as final."

http://msdn2.microsoft.com/en-us/lib...t6(VS.71).aspx

[cfps.Christian]

On Dec 12, 7:15 am, Mike <[e-mail]:

According to the MSDN (see reference below), it is possible to change
a base class function from public to private. How is this done? I've
tried using "new", but the function is still accessible.

From MSDN:
"A derived type can hide an inherited member by defining a new member
with the same signature. This might be done to make a previously
public member private or to define new behavior for an inherited
method that is marked as final."

http://msdn2.microsoft.com/en-us/lib...t6(VS.71).aspx

Base:
public void DoSomething()
{}

Derived:
private new string DoSomething()
{ return ""; }

its either that or new private string -
The term as I know its used in VB is shadowing methods

[Mike]

Using "new" does not do it. Perhaps it appears to work for you because
you also changed the return type from void to string?

On Dec 12, 8:27 am, "cfps.Christian" <[e-mail]:

On Dec 12, 7:15 am, Mike <[e-mail]:

According to the MSDN (see reference below), it is possible to change
a base class function from public to private. How is this done? I've
tried using "new", but the function is still accessible.

From MSDN:
"A derived type can hide an inherited member by defining a new member
with the same signature. This might be done to make a previously
public member private or to define new behavior for an inherited
method that is marked as final."

http://msdn2.microsoft.com/en-us/lib...t6(VS.71).aspx

Base:
public void DoSomething()
{}

Derived:
private new string DoSomething()
{ return ""; }

its either that or new private string -
The term as I know its used in VB is shadowing methods

[James Crosswell]

Mike wrote:

Thanks Jon, but why does the MSDN say it's possible?

Also, I would tend to disagree with the "don't derive from it"
approach. I can't see the benefit in creating a whole new class that
is 99% redundant code. There is a function in the base class that has
parameters. My derived class does not need the parameters because it
always knows what the values should be. I want to replace that
function with one that takes no parameters. Is there another approach
I have overlooked?

You don't need to get rid of the old method then - simply oveload it
with your new method.

As for the philosophical discussion, if you were able to remove methods
from classes that you inherited from then .NET wouldn't be able to
support polymorphism... which is a pretty big price to pay for the
fairly rare case in which you'd want to do what you were suggesting.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net

[Jon Skeet [C# MVP]]

On Dec 12, 2:20 pm, Mike <[e-mail]:

Thanks Jon, but why does the MSDN say it's possible?

Basically it's badly written.

Also, I would tend to disagree with the "don't derive from it"
approach. I can't see the benefit in creating a whole new class that
is 99% redundant code. There is a function in the base class that has
parameters. My derived class does not need the parameters because it
always knows what the values should be. I want to replace that
function with one that takes no parameters. Is there another approach
I have overlooked?

Create a parameterless overload of the method which then calls the one
that takes parameters.

You should ask yourself what should happen if someone calls the method
with a *different* set of parameters though. If you can't handle that,
then you shouldn't be deriving from the class.

Note that you don't always need to reimplement the same functionality
with redundant code, however - use aggregation instead of derivation,
i.e. create an instance of the other class "inside" your class, rather
than deriving from it. Sometimes that won't work, but often it will.

Jon

[Mike]

Thanks for the info. Yes, overloading is needed but I never want the
old method called outside my class because passing the wrong values
will cause problems. I am not really talking about removing the
function, just changing it from public to private. For now, I have
overridden the function I want to hide so it throws an exception when
called. Not pretty, but it keeps anyone from using it.

Thanks.

On Dec 12, 10:35 am, James Crosswell <[e-mail]:

Mike wrote:

Thanks Jon, but why does the MSDN say it's possible?

Also, I would tend to disagree with the "don't derive from it"
approach. I can't see the benefit in creating a whole new class that
is 99% redundant code. There is a function in the base class that has
parameters. My derived class does not need the parameters because it
always knows what the values should be. I want to replace that
function with one that takes no parameters. Is there another approach
I have overlooked?

You don't need to get rid of the old method then - simply oveload it
with your new method.

As for the philosophical discussion, if you were able to remove methods
from classes that you inherited from then .NET wouldn't be able to
support polymorphism... which is a pretty big price to pay for the
fairly rare case in which you'd want to do what you were suggesting.

Best Regards,

James Crosswell
Microforge.net LLChttp://www.microforge.net

[Scott Roberts]

Also, I would tend to disagree with the "don't derive from it"

approach. I can't see the benefit in creating a whole new class that
is 99% redundant code. There is a function in the base class that has
parameters. My derived class does not need the parameters because it
always knows what the values should be. I want to replace that
function with one that takes no parameters. Is there another approach
I have overlooked?

As others have said, you can simply overload the method. There typically
isn't a problem with users of your class calling the base method (if they
know the parameters). If you absolutely don't want users of your class to
call the base method, override that method and have it either call the
method w/o parameters or throw an exception. You can also add the "Obsolete"
attribute to the overridden method so that users of your class will get a
compiler warning if they try to use it.

Example:

[Obsolete("Use the generic NewObject<Tcall for maximum efficiency.")]
public PersistentObject NewObject(Type objectType, object aKey)

[Armin Zingler]

"Mike" <ML****@hotmail.comschrieb

Ahh, but you don't inherit everything. If I have a constructor in my
base class that takes parameters, my derived class is not required
to have a constructor with the same parameters. The derived class
can
have a constructor with no parameters while passing hard coded
values to the base constructor. That is basically what I want to do
with my member function.

No, constructors are not inherited because constructors determine how you
can create an instance of the class.
Armin