OdeToCode IC Logo

Visitors and Multiple Dispatch

Monday, March 10, 2008

The visitor pattern is an elegant solution to a specific class of problems, but also comes with drawbacks in mainstream programming languages. There are various techniques one can us to minimize the drawbacks, however. This weekend I found some old but good articles harnessing the power of visitor while removing some of the pain:

Both Brad and Kzu use reflection to effectively achieve multiple dispatch. The typical multiple dispatch mechanism used to implement the visitor pattern is a drag on maintenance and forces the pattern implementation to bleed into the visitor's targets – Brad's post shows all the gory details before he goes on the show a solution using reflection. Multiple dispatch isn't just a problem in C#, C++, and Java – it's also a problem in dynamic languages like Python and Ruby. Only a handful of languages inherently use multiple dispatch, or multimethods, with Common Lisp being the most notable.

I tried a dispatch mechanism using Expression<T> today, but (in case you don't want to read any further) did not get a satisfactory result. If you keep reading, maybe you can think of something I missed. 

Given these classes:

public class Employee
{
    
public string Name { get; set; }
}

public class Manager : Employee
{
}

How can you write a class like the following?

public class EmployeeReport
{
    
public void Generate(IEnumerable<Employee> employees)
    {
        
foreach (Employee employee in employees)
        {
            Visit(employee);
        }
    }

    
void Visit(Employee employee)
    {
        
// employee specific work ...
        Console.WriteLine("Visiting employee {0}", employee.Name);
    }

    
public void Visit(Manager manager)
    {
        
// manager specific work ...
        Console.WriteLine("Visiting manager {0}", manager.Name);
    }
}

The compiler will lay down code to invoke the Visit method that accepts an Employee reference, even when we really are referencing a Manager object at runtime. We need some mechanism that will thunk us into the best method based on the runtime type of the parameter, preferably without using a switch statement. A naïve try might look like the following:

public void Generate(IEnumerable<Employee> employees)
{
    
foreach (Employee employee in employees)
    {
        DispatchVisit(employee);
    }
}

void DispatchVisit(Employee visitee)
{
    
Expression<Action<Employee>> expression = e => this.Visit(e);
    expression.Compile().Invoke(visitee);
}

Even though this code is generating IL at runtime via Compile, it still invokes the wrong method when we reach a Manager object. At compile time the compiler generates an expression tree to invoke the Visit accepting an Employee reference. We could go into the expression and make modifications to the Body before we call Compile, or we could build an expression tree manually. Either way, we need to pick out the exact method we need at runtime using the type of the parameter and a call to GetMethod:

void DispatchVisit(Employee visitee)
{
    
MethodInfo methodInfo = this.GetType().GetMethod(
                                
"Visit", new Type[] { visitee.GetType() });
    
    
ParameterExpression e = Expression.Parameter(visitee.GetType(), "e");
    
LambdaExpression expression =
        
Expression.Lambda(
            
Expression.Call(
                
Expression.Constant(this, typeof(EmployeeReport)),
                methodInfo,
                e),
             e);

    
    expression.Compile().DynamicInvoke(visitee);
}

This code works, because we are now getting a MethodInfo object that will reference Visit(Manager employee) when we have a manger object at runtime. But, the code is starting to look just as hairy as any other code generation technique, and we haven't even tried to address caching the compiled expression for performance, or moving up to an Expression<T>.