views:

155

answers:

4

Hi all

Why is new/override required on abstract methods but not on virtual methods?

Sample 1:

abstract class ShapesClass
{
    abstract public int Area(); // abstract!
}

class Square : ShapesClass
{
    int x, y;

    public int Area() // Error: missing 'override' or 'new'
    {
        return x * y;
    }
}

The compiler will show this error: To make the current member override that implementation, add the override keyword. Otherwise add the new keyword

Sample 2:

class ShapesClass
{
    virtual public int Area() { return 0; } // it is virtual now!
}

class Square : ShapesClass
{
    int x, y;

    public int Area() // no explicit 'override' or 'new' required
    {
        return x * y;
    }
}

This will compile fine, by hiding the method by default.

I fully understand the technical differences. However I wonder why the language was designed that way. Wouldn't it be better to have the same restriction in "Sample 2" as well? I mean in most cases if you create a method with the same name as in the parent class, you usually intent to override it. So I think explicitly stating Override/New would make sense on virtual methods as well.

Is there a design-wise reason for this behavior?

Update: The 2nd sample actually causes a warning. The first sample shows an error because the subclass is required to implement the abstract method. I didn't see the warning in VS.. makes perfectly sense to me now. Thanks.

+1  A: 

The difference is that the abstract method has to be overridden, but the virtual doesn't.

It's an error to inherit the abstract class (in a non-abstract class) without implementing all abstract members, but you only get a warning when inheriting from the class without specifying override or new for the virtual method.

Guffa
A: 

I think in the first way you get the compiler error, because the abstract method is hidden and not implemented (so effectively your class is wrong, and it would be difficult to figure out why). In the second case you get only a warning, because the class is usable.

Grzenio
+5  A: 

Using either the C# 3.0 compiler as shipped in .NET 3.5 SP1, or the C# 4.0 compiler as shipped in .NET 4.0, I get the following error for your first example:

error CS0534: 'ConsoleApplication3.Square' does not implement inherited abstract member 'ConsoleApplication3.ShapesClass.Area()'

And the following warning for the second one:

warning CS0114: 'ConsoleApplication3.Square.Area()' hides inherited member 'ConsoleApplication3.ShapesClass.Area()'. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword.

In the first case it's an error because you aren't actually overriding the base method, which means there is no implementation for the abstract method in a concrete class. In the second case it's a warning because the code is technically correct, but the compiler suspects that it isn't what you meant. This is one of the reasons it's generally a good idea to enable the "treat warnings as errors" compilation setting.

So I can't repro your behaviour, and the behaviour of the compiler looks right to me. Which version of the compiler are you using?

Greg Beech
Makes absolutely sense, thanks.Seems like I hided the warnings in this project, so I didn't see this behavior.
driAn
+3  A: 

Here's the answer straight from the C# spec.

...hiding an accessible name from an inherited scope causes a warning to be reported. In the example

class Base
{
    public void F() {}
}
class Derived: Base
{
    public void F() {}      // Warning, hiding an inherited name
}

the declaration of F in Derived causes a warning to be reported. Hiding an inherited name is specifically not an error, since that would preclude separate evolution of base classes. For example, the above situation might have come about because a later version of Base introduced an F method that wasn’t present in an earlier version of the class. Had the above situation been an error, then any change made to a base class in a separately versioned class library could potentially cause derived classes to become invalid. The warning caused by hiding an inherited name can be eliminated through use of the new modifier:

class Base
{
    public void F() {}
}
class Derived: Base
{
    new public void F() {}
}

The new modifier indicates that the F in Derived is “new”, and that it is indeed intended to hide the inherited member.

Enigmativity