This is more a matter of virtual vs. non-virtual methods, and how the invocation occurs. The portion of the spec you are quoting deals with method calls on a variable - calling bcDerived.SomeMethod()
, not calling foo.SomeMethod(bcDerived)
.
The specification you are quoting refers to the case where you have non-virtual methods:
public class A
{
public void Foo() { Console.WriteLine("A.Foo"); }
public virtual void Bar() { Console.WriteLine("A.Bar"); }
}
public class B : A
{
public new void Foo() { Console.WriteLine("B.Foo"); }
public override void Bar() { Console.WriteLine("B.Bar"); }
}
Then the method called will be determined by the compiler, at compile time, so doing:
A someInst = new B();
someInst.Foo();
Will cause this to call A.Foo()
, no matter what subclass of A is being referred to by someInst
, since this is a non-virtual method.
If you have a virtual method, however, the callvirt
instruction is specified by the compiler, which moves the decision to runtime. This means that:
someInst.Bar();
Will call B.Bar()
, not A.Bar()
.
In your case, you're not calling a virtual method (in the sense that the spec is referring to), but doing standard method resolution. 7.5.3 of the C# Spec deals with Overload resolution in detail. In your case, the argument list (bcDerived
) is inspected by the compiler, and seen to be defined as type BaseClass
. The "best match" for this is going to be public virtual void Method(BaseClass d)
as the the parameter list directly matches the argument list, so that is used at compile time.
Method overload resolution, if you look at the specification, doesn't directly take virtual method calls into effect - it only looks at implicit conversions between types.