Changing access modifier levels in a derived class

[Edward Diener]

In C++ one can change the access level in a derived class by the "using"
keyword. So, for instance, a public method in a base class can be made
private in a derived class. Is there any way of doing this in C# ?

[Daniel O'Connell [C# MVP]]

"Edward Diener" <di***************@ORsoftware.com> wrote in message
news:O8**************@TK2MSFTNGP12.phx.gbl...

In C++ one can change the access level in a derived class by the "using"
keyword. So, for instance, a public method in a base class can be made
private in a derived class. Is there any way of doing this in C# ?

No, C# does not allow for the changing of accessibility of methods(not sure
about IL, however).

Out of curiosity, what kind of scenarios would this allow? Does it have a
use outside of maneveruing around badly designed base classes, which is the
only thing I can think of off hand?

[Bruce Wood]

Not true.

C# does allow you to change accessibility of base class items in a
derived class, but with caveats.

First, (perhaps obviously) you can widen access. You can override a
protected base class item and declare the override public in the
derived class.

Second, (and I think this is what Edward was asking), you can use the
"new" keyword to indicate that your derived class has a new
implementation for a base class item. The "new" derived item can have
any access at all, including (usually) narrower access. So if you have
a protected method in your base class, you can declare that same method
with the "new" keyword in your derived class and make it private.

However, it's not that simple.

Because the "new" derived class method is not an override (it's a
redefinition), if someone casts your derived class object to its base
class, then the base class method will be called instead of the derived
class method. Remember: the "new" derived class method is not an
override and does not create polymorphic behaviour. For example:

class A
{
public virtual int Add(int a, int b)
{ ... }
}

class B : A
{
public new int Add(int a, int b)
{ ... }
}

B aB = new B();
int x = aB.Add(1, 2);
A anA = aB;
int y = anA.Add(1, 2);

In this example, the first call to aB.Add() would call B.Add. The
second call, anA.Add, would call A.Add(). If B.Add had been declared
"public override" instead of "public new", both calls would have
invoked B.Add().

You can, of course, declare B.Add "private new" or give it whatever
access level you like.

[Daniel O'Connell [C# MVP]]

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...

Not true.

C# does allow you to change accessibility of base class items in a
derived class, but with caveats.

First, (perhaps obviously) you can widen access. You can override a
protected base class item and declare the override public in the
derived class.

I've love to see an example of this. I just tried it and got this error:

'Test1.Test.TestMethod()': cannot change access modifiers when overriding
'protected' inherited member 'Test.Program.TestMethod()'

[Joakim Karlsson]

This compiles, but there are many reasons to avoid it.

public class A
{
protected void Foo()
{
Console.WriteLine("Foo");
}
}

public class A : B
{
public new void Foo()
{
base.Foo();
}
}

Regards,
Joakim

Daniel O'Connell [C# MVP] wrote:

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...

Not true.

C# does allow you to change accessibility of base class items in a
derived class, but with caveats.

First, (perhaps obviously) you can widen access. You can override a
protected base class item and declare the override public in the
derived class.

I've love to see an example of this. I just tried it and got this error:

'Test1.Test.TestMethod()': cannot change access modifiers when overriding
'protected' inherited member 'Test.Program.TestMethod()'

[Joakim Karlsson]

Of course that should be

public class A
{
protected void Foo()
{
Console.WriteLine("Foo");
}
}

public class B : A
{
public new void Foo()
{
base.Foo();
}
}

Regards,
Joakim

Joakim Karlsson wrote:

This compiles, but there are many reasons to avoid it.

public class A
{
protected void Foo()
{
Console.WriteLine("Foo");
}
}

public class A : B
{
public new void Foo()
{
base.Foo();
}
}

Regards,
Joakim

Daniel O'Connell [C# MVP] wrote:

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...

Not true.

C# does allow you to change accessibility of base class items in a
derived class, but with caveats.

First, (perhaps obviously) you can widen access. You can override a
protected base class item and declare the override public in the
derived class.

I've love to see an example of this. I just tried it and got this error:

'Test1.Test.TestMethod()': cannot change access modifiers when
overriding 'protected' inherited member 'Test.Program.TestMethod()'

[Joakim Karlsson]

...and of course I should have read the entrire thread before jumping in
like this. I see you guys have already covered this.

My bad.

Regards,
Joakim

Joakim Karlsson wrote:

Of course that should be

[Bruce Wood]

You are absolutely correct. My bad. An overridden item must have
exactly the same signature as the base class item.

In order to narrow _or widen_ the access to an item, you must declare
it "new", and in so doing you give up polymorphism.

Again, my apologies: I was confusing C# with Java, which does allow
increasing the visibility of an overridden member in the subclass. Does
anyone know why C# doesn't allow this?

[Daniel O'Connell [C# MVP]]

> Again, my apologies: I was confusing C# with Java, which does allow

increasing the visibility of an overridden member in the subclass. Does
anyone know why C# doesn't allow this?

I've no idea. My best guess would be that they wanted to avoid exposing a
method accidentally by typing the wrong accessibility modifier(public
override instaed of protected override). Personally I don't think its much
of a loss, new can be used or an entirely new method defined.

Assuming the runtime permits this anyway, I've yet to work up the energy to
pour through the spec and determine if its a spec feature or not(Although I
suspect the spec permits it, since explicit interface implementations are
not public).

[Jon Skeet [C# MVP]]

Bruce Wood <br*******@canada.com> wrote:

Not true.

C# does allow you to change accessibility of base class items in a
derived class, but with caveats.

First, (perhaps obviously) you can widen access. You can override a
protected base class item and declare the override public in the
derived class.
No you can't. You can in Java, but not in C#. If you try it, you get an
error message such as:

Test.cs(11,26): error CS0507: 'Derived.Foo()': cannot change access
modifiers when overriding 'protected' inherited member 'Base.Foo()'
Second, (and I think this is what Edward was asking), you can use the
"new" keyword to indicate that your derived class has a new
implementation for a base class item. The "new" derived item can have
any access at all, including (usually) narrower access. So if you have
a protected method in your base class, you can declare that same method
with the "new" keyword in your derived class and make it private.

That's not changing the accessibility of a base class item though. It's
introducing a new item with the same name, as you then say.

It's a shame that you can't widen access in C# as you can in Java, but
I'm glad you can't narrow it as that would break Liskov's
substitutability rule (depending on what it actually meant to narrow
the access, of course).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Edward Diener]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...

"Edward Diener" <di***************@ORsoftware.com> wrote in message
news:O8**************@TK2MSFTNGP12.phx.gbl...

In C++ one can change the access level in a derived class by the "using"
keyword. So, for instance, a public method in a base class can be made
private in a derived class. Is there any way of doing this in C# ?

No, C# does not allow for the changing of accessibility of methods(not
sure about IL, however).

Out of curiosity, what kind of scenarios would this allow? Does it have a
use outside of maneveruing around badly designed base classes, which is
the only thing I can think of off hand?

Deriving my own class from a .NET framework base class I might wish to
remove some functionality of that base class from the end-programmer of my
derived class. This seems to me a fairly common possibility.

[Daniel O'Connell [C# MVP]]

"Edward Diener" <di***************@ORsoftware.com> wrote in message
news:eu**************@TK2MSFTNGP10.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...

"Edward Diener" <di***************@ORsoftware.com> wrote in message
news:O8**************@TK2MSFTNGP12.phx.gbl...

In C++ one can change the access level in a derived class by the "using"
keyword. So, for instance, a public method in a base class can be made
private in a derived class. Is there any way of doing this in C# ?

No, C# does not allow for the changing of accessibility of methods(not
sure about IL, however).

Out of curiosity, what kind of scenarios would this allow? Does it have a
use outside of maneveruing around badly designed base classes, which is
the only thing I can think of off hand?

Deriving my own class from a .NET framework base class I might wish to
remove some functionality of that base class from the end-programmer of my
derived class. This seems to me a fairly common possibility.

Hmm, I suppose it would have some value, although I would question the
point. The end user could cast down to the base object and make the call
anyway, and doing so does violate the oft-touted Liskov principal.

Have you considered overriding it and applying one of the non browse
attributes(don't know 'em off hand, sorry) so it won't show up in
intellisense?

[Bruce Wood]

I have run across this problem a couple of times in C#. For example, I
wrote an XmlFragmentReader, which is based on XmlTextReader. It's a
very close fit, but not quite: some methods of XmlTextReader don't make
any sense in the context of the derived class. I settled for returning
null or doing nothing if they're called, but it would have been nicer
to be able to hide them in some way other than using "new".

I agree, however, that it's unclear what would be the semantics of
narrowing access via an override. It's a shame that you can't widen
access á la Java, though: I've also found some situations in which
that would be handy.

[Daniel O'Connell [C# MVP]]

(hmm, don't know why but OE didn't comment this on reply...I really need to
find a new newsreader)

I do think that widening accessbility would be nice(although I don't think
it should be implicit by any means), but narrowing still bothers me.

In your example, either it was the wrong base class or the base class isn't
granular enough. Unfortuantly with the framework we are stuck with what
there already is. Hiding the method still would not achieve anything better
than new would...the same method could be called from a base class
reference.

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
I have run across this problem a couple of times in C#. For example, I
wrote an XmlFragmentReader, which is based on XmlTextReader. It's a
very close fit, but not quite: some methods of XmlTextReader don't make
any sense in the context of the derived class. I settled for returning
null or doing nothing if they're called, but it would have been nicer
to be able to hide them in some way other than using "new".

I agree, however, that it's unclear what would be the semantics of
narrowing access via an override. It's a shame that you can't widen
access á la Java, though: I've also found some situations in which
that would be handy.

[Bruce Wood]

Yes, that's what I meant by "unclear semantics". If you required that a
method with narrowed access really be hidden--even when the object is
cast to a base class--then you break compile-time type checking. That's
why they added the "new" keyword to the language. I can understand not
allowing access narrowing because of this.

Widening accessibility would be nice, though, and doesn't come with the
same semantic difficulties.