New Keyword in Method Signature

new keyword in method signature

New keyword reference from MSDN:

MSDN Reference

Here is an example I found on the net from a Microsoft MVP that made good sense:
Link to Original

public class A
{
   public virtual void One();
   public void Two();
}

public class B : A
{
   public override void One();
   public new void Two();
}

B b = new B();
A a = b as A;

a.One(); // Calls implementation in B
a.Two(); // Calls implementation in A
b.One(); // Calls implementation in B
b.Two(); // Calls implementation in B

Override can only be used in very specific cases. From MSDN:

You cannot override a non-virtual or
static method. The overridden base
method must be virtual, abstract, or
override.

So the 'new' keyword is needed to allow you to 'override' non-virtual and static methods.

Is using new keyword in method signature generally just for readability?

Implicit in this question: why isn't the new keyword required when hiding a base class member? The reason is the brittle base class problem. Suppose you have a library:

public class Base
{
    public void M() { }
}

and you've derived a class in your own code base:

public class Derived : Base
{
    public void N() { }
}

Now, the library authors release a new version, adding another method to Base:

public class Base
{
    public void M() { }
    public void N() { }
}

If the new keyword were required for method hiding, your code now fails to compile! Making the new keyword optional means that all you now have is a new warning to worry about.

EDIT

As Eric Lippert points out in his comment, "new warning to worry about" drastically understates the purpose of the warning, which is to "wave a big red flag." I must have been in a hurry when I wrote that; it's annoying when people reflexively view warnings as annoyances to be tolerated rather than treating them as useful information.

EDIT 2

I finally found my source for this answer, which, of course, is one of Eric's posts: https://stackoverflow.com/a/8231523/385844

How is the new keyword used to hide a method?

new is used for 3 different things. You could say there are 3 different keywords with the same name.

1. It's an operator, used to invoke constructors. Example: new object();

2. It's a modifier, used to hide an inherited member from a base class member. Example:

   class Base {
       public void MyMethod() {
           //Do stuff
       }
   }
   
   class Derived : Base {
       public new void MyMethod() {
           //Do other stuff
       }
   }
   

3. It's a generic type constraint, used to indicate that a generic type parameter has a parameterless constructor. Example:

   class MyGenericClass<T> : where T : new() { ... }
   

Source: new

How to Create a Method with 'new' keyword in its method signature using codedom

Something like:

CodeMemberMethod myMethodMethod = new CodeMemberMethod();
myMethodMethod.Attributes = MemberAttributes.Private | MemberAttributes.New;
myMethodMethod.Name = "MyMethod";

It is a MemberAttributes: MemberAttributes.New.

Why do we need the new keyword and why is the default behavior to hide and not override?

Good questions. Let me re-state them.

Why is it legal to hide a method with another method at all?

Let me answer that question with an example. You have an interface from CLR v1:

interface IEnumerable
{
    IEnumerator GetEnumerator();
}

Super. Now in CLR v2 you have generics and you think "man, if only we'd had generics in v1 I would have made this a generic interface. But I didn't. I should make something compatible with it now that is generic so that I get the benefits of generics without losing backwards compatibility with code that expects IEnumerable."

interface IEnumerable<T> : IEnumerable
{
    IEnumerator<T> .... uh oh

What are you going to call the GetEnumerator method of IEnumerable<T>? Remember, you want it to hide GetEnumerator on the non-generic base interface. You never want that thing to be called unless you're explicitly in a backwards-compat situation.

That alone justifies method hiding. For more thoughts on justifications of method hiding see my article on the subject.

Why does hiding without "new" cause a warning?

Because we want to bring it to your attention that you are hiding something and might be doing it accidentally. Remember, you might be hiding something accidentally because of an edit to the base class done by someone else, rather than by you editing your derived class.

Why is hiding without "new" a warning rather than an error?

Same reason. You might be hiding something accidentally because you've just picked up a new version of a base class. This happens all the time. FooCorp makes a base class B. BarCorp makes a derived class D with a method Bar, because their customers like that method. FooCorp sees that and says hey, that's a good idea, we can put that functionality on the base class. They do so and ship a new version of Foo.DLL, and when BarCorp picks up the new version, it would be nice if they were told that their method now hides the base class method.

We want that situation to be a warning and not an error because making it an error means that this is another form of the brittle base class problem. C# has been carefully designed so that when someone makes a change to a base class, the effects on code that uses a derived class are minimized.

Why is hiding and not overriding the default?

Because virtual override is dangerous. Virtual override allows derived classes to change the behaviour of code that was compiled to use base classes. Doing something dangerous like making an override should be something you do consciously and deliberately, not by accident.

Use new keyword in c#

Yes, you are correct, it is for better readability in this situation.

But check carefully you should have a warning for not using new when hiding the base method.

You can read more here:
http://msdn.microsoft.com/en-us/library/vstudio/435f1dw2.aspx

The new keyword (for methods) and OOP

I think the principle that applies is the Liskov Substitution Principle (LSP) and I would agree that you shouldn't have a method that only differs in it's output type in an inheriting class. Generally one would expect an implementing class to have the same semantics with respect to a method defined by an ancestor regardless of whether it's referred to from a variable typed as the base class or the implementing class.

The thing with principles, however, is that they're principles, not laws and it may, occasionally, be necessary to violate them. Having said that, I don't recall using the new keyword for a long, long time if ever, to replace a parent class implementation.

I would regard the need for a new method as a code smell - a hint that there's probably something wrong with my design. Perhaps I'm trying to do too much in that class hierarchy or I've chosen the wrong pattern to apply.

---

Related Topics