If the generic type argument (of either a calling class or calling method) is constrained with where T : Base
the new method in T == Derived is not called, instead the method in Base is called.
Why is the type T ignored for method call even though it should be known before run time?
Update: BUT, when the constraint is using an interface like where T : IBase
the method in Base class is called (not the method in interface, which is also impossible).
So that means the system actually is able to detect the types that far and go beyond the type constraint! Then why doesn't it go beyond the type constraint in case of class-typed constraint?
Does that mean that the method in Base class that implements the interface has implicit override keyword for the method?
Test code:
public interface IBase
{
void Method();
}
public class Base : IBase
{
public void Method()
{
}
}
public class Derived : Base
{
public int i = 0;
public new void Method()
{
i++;
}
}
public class Generic<T>
where T : Base
{
public void CallMethod(T obj)
{
obj.Method(); //calls Base.Method()
}
public void CallMethod2<T2>(T2 obj)
where T2 : T
{
obj.Method(); //calls Base.Method()
}
}
public class GenericWithInterfaceConstraint<T>
where T : IBase
{
public void CallMethod(T obj)
{
obj.Method(); //calls Base.Method()
}
public void CallMethod2<T2>(T2 obj)
where T2 : T
{
obj.Method(); //calls Base.Method()
}
}
public class NonGeneric
{
public void CallMethod(Derived obj)
{
obj.Method(); //calls Derived.Method()
}
public void CallMethod2<T>(T obj)
where T : Base
{
obj.Method(); //calls Base.Method()
}
public void CallMethod3<T>(T obj)
where T : IBase
{
obj.Method(); //calls Base.Method()
}
}
public class NewMethod
{
unsafe static void Main(string[] args)
{
Generic<Derived> genericObj = new Generic<Derived>();
GenericWithInterfaceConstraint<Derived> genericObj2 = new GenericWithInterfaceConstraint<Derived>();
NonGeneric nonGenericObj = new NonGeneric();
Derived obj = new Derived();
genericObj.CallMethod(obj); //calls Base.Method()
Console.WriteLine(obj.i);
genericObj.CallMethod2(obj); //calls Base.Method()
Console.WriteLine(obj.i);
genericObj2.CallMethod(obj); //calls Base.Method()
Console.WriteLine(obj.i);
genericObj2.CallMethod2(obj); //calls Base.Method()
Console.WriteLine(obj.i);
nonGenericObj.CallMethod(obj); //calls Derived.Method()
Console.WriteLine(obj.i);
nonGenericObj.CallMethod2(obj); //calls Base.Method()
Console.WriteLine(obj.i);
nonGenericObj.CallMethod3(obj); //calls Base.Method()
Console.WriteLine(obj.i);
obj.Method(); //calls Derived.Method()
Console.WriteLine(obj.i);
}
}
Output:
0
0
0
0
1
1
1
2
It is because
T
is constrained to have the semantics ofBase
. I can't tell you exactly what is going on with the type binding at runtime, but this is my educated guess.You are not properly overriding the method, but instead hiding via "new", if you use a reference to the base class you bypass any hiding. This is where hiding falls down.
Members that hide other members are only honoured if you are using a reference to the type in which they are hidden. You can always bypass a hidden member by using a reference to the base class:
To properly override a method and have this code work, mark the method as
virtual
in the base class andoverride
it in the derived class.You can prove this, change your generic constraint to be
where T : Derived
and it should hit the "new" member.The
new
keyword simply hides the method instead of overloading it. The reason your non-genericCallMethod
appears to work as expected is because the method signature expects aDerived
instead of aBase
.Generics aren't really the culprit here. If you change the method signature to
CallMethod(Base obj)
, you'll see the same "unexpected" behavior as the generic implementation and get the following output:If you make
Base.Method
virtual and override it withDerived.Method
like so:You'll get the following output:
Edit: updated to match question's updated output.
Except when using
dynamic
objects, C# always binds methods at compile time--even when using generics. Virtual method calls are bound to virtual method slots rather than to the implementing methods, so that when they are performed on derived-class objects they will be directed to the derived-class implementations; although the methods to which the slots point will be determined at run time, the binding to the slots occurs at compile time. If a derived-class method is declarednew
rather thanoverride
, code which is bound using the derived class will use the derived-class method, but code which is bound using the base class will use the base-class method.To understand why this has to be the case, imagine if it weren't. What should happen if class
Base
declares a methodint Foo()
, and a classDerived:Base
declares anew string Foo()
. If a generic class with constraintT:Base
tries to call methodFoo
on an object of typeT
, what should the return type of that method be?That's due to the nature of the operator new: New unlike override, create a function with the same name as the base one, which mask the base method but doesn't override it.
Therefor, without a proper cast, the original method will be called if the reference is of type Base.