How does polymorphism work with undefined intermediate types in C#?

Question

In the following code, I would have expected calling a.Generate(v) would have resulted in calling V.Visit(A a), since when Generate is called this is of type A. Hoewever, it appears that this is seen as being an Inter instead.

Is it possible to have the intended behaviour without explicitly implementing the (identical) method in both A and B and only on the shared base class? If so, how can it be acheived?

using System;
using System.Diagnostics;

namespace Test {
    class Base {}
    class Inter: Base {
        public virtual void Generate(V v) {
            // `Visit(Base b)` and not `Visit(A a)` is called when calling
            // A.Generate(v). Why?
            v.Visit(this);
        }
    }

    class A: Inter {}
    class B: Inter {}

    class V {
        public void Visit(Base b) { throw new NotSupportedException(); }
        public void Visit(A a)    { Trace.WriteLine("a"); }
        public void Visit(B b)    { Trace.WriteLine("b"); }
    }

    class Program {
        static void Main() {
            V v = new V();
            A a = new A();
            B b = new B();

            a.Generate(v);
            b.Generate(v);
        }
    }
}

Edit It was suggested in the answers that the code above is not polymorphic. I would object to that. V.Visit is polymorphic.

Hmmm... I think the only way to make that work is to implement Generate in both A and B. — Stephen Gross, Jan 30 '12 at 19:39

score 16 · Accepted Answer · answered Jan 30 '12 at 19:59

You are expecting the call to v.Visit(this) to determine which overload of Visit to call based on the run time types of both v and this.

Languages which have that feature are called "double virtual dispatch" languages. (Or, if more than two things are considered they are called "multiple virtual dispatch" languages, or "multimethod" languages.)

C# is not a double-virtual dispatch language; it is a single-virtual dispatch language when dispatch decisions are made at compile time. That is, the decision of which overload to choose is made on the basis of the runtime type of the receiver, but the compile-time types of the arguments.

Now, in your case, C# does not use single virtual dispatch because the call to Visit is not even a virtual call in the first place! The fact that the call to Generate was a virtual call is completely irrelevant, and the fact that Visit is overloaded is also irrelevant. The dispatch to Visit is made non-virtually, so the dispatch logic is based entirely on the compile-time type of the receiver, v, and the argument this. Since the receiver is known to be of type V and the argument is known to be of type Inter, overload resolution must choose the best possible match given only that information. It cannot choose the versions of Visit that take A or B because those are more derived than the known argument type, Inter. It must choose the overload with the less derived formal parameter type, Base.

If you wish to achieve double-virtual dispatch in C#, there are two standard ways to do it. First, you can use dynamic; with dynamic, the analysis is performed at runtime using the runtime types. Simply cast the receiver and the arguments to dynamic and the compiler will take care of it for you. That imposes a significant performance cost though.

The second standard way to do it is to use the Visitor Pattern, which you can find out about by searching the internet for it. I suspect based on the names of your methods that you are trying to implement the Visitor Pattern already; this is not the right way to do it.

Randolpho · Answer 2 · 2012-01-30T20:08:39.123

2

The problem is that the Generate method is defined in the Iter class. So when the Generate method is called, it passes a reference to an Iter.

If you want to pass A or B in, make Generate virtual and override it at the A and B level to pass in the properly cast value.

edited Jan 30 '12 at 20:08

answered Jan 30 '12 at 19:24

Randolpho

55,384
17
145
179

Overriding in `A` and `B` is exactly what I'd like to avoid, as the `Generate` method in both would be exactly the same. – joce Jan 30 '12 at 19:31
Making `Generate` virtual doesn't change anything. – joce Jan 30 '12 at 19:37
Isn't Generate() already declared virtual in the original question? – Stephen Gross Jan 30 '12 at 19:59
1

@StephenGross No, `Generate` wasn't virtual in the original question. – Randolpho Jan 30 '12 at 20:07
2

@Randolpho Ah! Another reason SO needs a more clearly visible edit history :) – Stephen Gross Jan 30 '12 at 20:12

score 2 · Answer 3 · answered Jan 30 '12 at 19:27

2

That is not polymorphic code, polymorphic code has dynamic binding which determines which method to call at runtime. Both objects must have a similar base class with virtual methods to do this dynamic binding. Right now your binding is static and is determined at compile time.

answered Jan 30 '12 at 19:27

Matthew

24,703
9
76
110

V.Visit is polymorphioc: http://en.wikipedia.org/wiki/Polymorphism_(computer_science)#Ad-hoc_polymorphism – joce Jan 30 '12 at 19:33
`V.Visit` is not polymorphic. That's called operation overloading. Your link even tells you that. – Randolpho Jan 30 '12 at 20:17

score 1 · Answer 4 · answered Jan 30 '12 at 19:27

What do you expect exactly?

public void Visit(Base b) { Trace.WriteLine(b.GetType().Name);  }

Somehow, the compiler compiles one version of the code for v.Visit(this). It can't compile different versions for each call instance according to the real tpye of the argument passed.

In a polymorphic design, Inter and each of its derived classes are responsible for doing "personal" stuff.

public void Visit(Base b) { b.VisitedBy(v);  }

where VisitedBy() is a virtual function.

I expect the code in `Main()` to never call `V.Visit(Base b)`. — joce, Jan 30 '12 at 19:29

How does polymorphism work with undefined intermediate types in C#?

4 Answers4

Linked