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

On Dec 12, 7:15 am, Mike <MLM...@hotmail.com> wrote:
> 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

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" <ge0193...@otc.edu> wrote:
> On Dec 12, 7:15 am, Mike <MLM...@hotmail.com> wrote:
>
> > 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

On Dec 12, 1:15 pm, Mike <MLM...@hotmail.com> wrote:
> 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.

You can't. You can create a new method which hides the old method, but
anyone calling "base.Foo()" will still get the old method.

If you don't want to inherit the functionality of a class, don't
derive from it. See Liskov's Substitution Principle:
http://en.wikipedia.org/wiki/Liskov_...tion_principle


Jon

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?

On Dec 12, 8:42 am, "Jon Skeet [C# MVP]" <sk...@pobox.com> wrote:
> On Dec 12, 1:15 pm, Mike <MLM...@hotmail.com> wrote:
>
> > 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.
>
> You can't. You can create a new method which hides the old method, but
> anyone calling "base.Foo()" will still get the old method.
>
> If you don't want to inherit the functionality of a class, don't
> derive from it. See Liskov's Substitution Principle:http://en.wikipedia.org/wiki/Liskov_...tion_principle
>
> Jon

"Mike" <MLM450@hotmail.com> schrieb
> 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.

The benefit is that it only contains the public members that you want to
offer to the class user - if you want it bullet proof. In addition, the code
doesn't have to be redundant/duplicated because the new class is a
proxy/wrapper delegating all calls to an internal instance of the class that
you are currently deriving from.

A general rule: If an object reference is made available, everything can be
done to the object. If you don't want this, either don't pass the reference,
or only pass a wrapper object.


> 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?

The question is, whether it is forbidden to call the base class' function
when accessing an instance of the derived class. If it is, see above.
Otherwise, if you want an /additional/ function without parameters, you can
add an overloaded method in the derived class.

By definition, inheritance means "inherit everything". "Inherit almost
everything" is not possible.


Armin


> On Dec 12, 8:42 am, "Jon Skeet [C# MVP]" <sk...@pobox.com> wrote:
> > On Dec 12, 1:15 pm, Mike <MLM...@hotmail.com> wrote:
> >
> > > 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.
> >
> > You can't. You can create a new method which hides the old method,
> > but
> > anyone calling "base.Foo()" will still get the old method.
> >
> > If you don't want to inherit the functionality of a class, don't
> > derive from it. See Liskov's Substitution
> > Principle:http://en.wikipedia.org/wiki/Liskov_...tion_principle
> >
> > Jon

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

On Dec 12, 2:20 pm, Mike <MLM...@hotmail.com> wrote:
> 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

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 <ja...@microforge.net> wrote:
> 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

On Dec 12, 3:48 pm, Mike <MLM...@hotmail.com> wrote:
> 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.

In other words, someone who has a reference to an instance of your
class and wants to treat it as an instance of the more general class
won't be able to, right?

That's breaking the substitution principle. Sometimes it's pragmatic
to do so, but it's worth being aware of it and avoiding it wherever
possible.

Jon