Hide and seek

re: Hide and seek

Patrick — Fri, 18 Jun 2010 17:14:49 GMT

"So what is the recommended way for a subclass to hide a function from the base class? A public implementation that throws an exception when called?"

I have no idea if this is a recommended way (I doubt it is) but here goes.

Use "new" to hide the method. In you new method throw the error. Then apply the EditorBrowsableAttribute on the method to hide it from intellisense. If it is not in intellisense then it does not exist right =). You do not get a compile time error but this may get you 90% of the way there.

re: Hide and seek

Maciej — Wed, 16 Jun 2010 22:37:30 GMT

oReally here is something about scope, declaration space and lifetime.:

blogs.msdn.com/.../what-s-the-difference-part-two-scope-vs-declaration-space-vs-lifetime.aspx

re: Hide and seek

Joren — Wed, 16 Jun 2010 08:45:57 GMT

If hiding only happens within the scope of a member (which Main is outside of), then if D.X were public, why does B.X appear to be hidden in Main? Is it only because of the betterness algorithm?

re: Hide and seek

oReally — Wed, 16 Jun 2010 02:24:36 GMT

You cant really hide a method, if someone really wants to call the "hidden" method they will always be able to.

Anyhow, IMHO if some class in you're inheritance chain needs to hide public inherited members then probably something is wrong with your class hierarchy to begin with. You should think more in a "has a" relationship than a "is a" type relationship in most of those cases.

re: Hide and seek

David — Wed, 16 Jun 2010 00:26:38 GMT

So what is the recommended way for a subclass to hide a function from the base class? A public implementation that throws an exception when called?

re: Hide and seek

oReally — Tue, 15 Jun 2010 16:14:12 GMT

Good to learn something new. I didn't realize freeborn's question had a catch to it, as D.X obviously does hide B.X in that case. I get lost with some of these terms in english (not my native language). Do you have any blog where you explain what we are exactly referring to when we talk about scope, domains, declaration spaces, etc?

re: Hide and seek

oReally — Mon, 14 Jun 2010 17:56:55 GMT

Yes it does. The new member is public so any call to it is within it's scope.

You are confusing scope with accessibility domain. The scope of an entity is the region of program text in which it is legal to refer to the entity by an unqualified name; a public field of a class is in scope only inside the class. Anywhere else you have to qualify its name to access it. The accessibility domain of a public member of a public class is everywhere; the accessibility domain is the region of program text where it is legal to refer to the entity by qualified or unqualified name.

The problem was that I was not calling out the specific part of the spec that dealt with the relationship between member lookup and hidden members. I've clarified the text.

- Eric

re: Hide and seek

freeborn — Mon, 14 Jun 2010 17:45:09 GMT

The specification says "A declaration of a new member hides an inherited member only within the scope of the new member.", but says nothing about the lower accessibility.

if we replace protected to public

class D : B { new public int X() }

D.X won't hide B.X in the main method?

Excellent question. The way I originally wrote this article implied what you stated, which of course is incorrect. I've clarified the text. The relevant portion of the spec is in the member lookup section. - Eric