When you’ve got a hammer…

… everything looks like a nail.
Type classes. In C#. Because I’ve got a hammer. Haskell gave it to me.

A what?

… a type class is a type system construct that supports ad hoc polymorphism. This is achieved by adding constraints to type variables in parametrically polymorphic types.

Uh… in English…

If you’re coming from an OO perspective (as I am) you can think of type classes as rather like an interface; with the additional ability to provide default implementations for their functions – making them perhaps rather more like abstract classes without fields in a type system with multiple inheritance, but that sounds more clunky.

Rather to be expected, the idea of type classes doesn’t fit well into an language based heavily around the OO-paradigm (like C#) but I thought it might be instructive (to myself even if to nobody else) to see how we could model something akin to them. What we’ll be doing below doesn’t interact nicely with inheritance and polymorphism, they they are somewhat orthogonal approaches and their intersection is at best confusing. It’s also a fairly terrible idea, but that should go without saying…

One way to describe what we’re trying to achieve would be to say that we wish to attach behaviours to a type not via its instances, but through a separate ‘static’ definition for that type. We also want membership to a type class to be enforced at compile time, and to be able to be members of multiple type classes simultaneously.

Equality for all (that opt-in)

I’m going to focus on the Eq type class here, but will be keeping in mind that this could be extended to other type classes.

First things first, we need a marker interface to declare our type as a member of the type class.

interface IEq { }

Next, we’re going to need a way for types to provide specific behaviour. It sound a bit odd to say, but inheritance seems the obvious choice here: it provides us the ability to override functions and is built-in to the language. One thing that we can’t restrict here is deriving classes adding fields/state – there are ways to enforce that but they’re more work and this is perfectly instructive for now.

public abstract class EqImpl<T>
    where T : IEq
{
    // we can require functions to be overridden...
    public abstract bool Equals(T a, T b);

    // or provide some default behaviour...
    public virtual bool NotEquals(T a, T b)
    {
        return !Equals(a, b);
    }
}

Now, we need a way for a type to actually specify its behaviour once it has declared itself a member of a type class, and a way for consumers of the type to access that behaviour.

For a class Foo we’ll do this by instantiating a ‘EqImpl‘ and storing it for use by consumers of Foo… this will obviously have to be done at runtime – if we could do this sort of thing at compile-time, we’d essentially already have our type classes already! The obvious place to do this is in the static constructor for Foo as we know this is going to be executed exactly once, and before Foo is ever instantiated. Again, we are unable to actually enforce that an implementation has actually been provided – we could provide a complete default implementation, but for simplicity I’ve not done that here.

public static class Eq<T>
    where T : IEq
{
    private static EqImpl<T> impl;

    public static bool Equals(T a, T b)
    {
        return impl.Equals(a, b);
    }
    
    public static bool NotEquals(T a, T b)
    {
        return impl.NotEquals(a, b);
    }

    public static void Register(EqImpl<T> impl)
    {
        Eq<T>.impl = impl;
    }
}
public class Foo : IEq
{
    static Foo()
    {
        Eq<Foo>.Register(new FooEqImpl());
    }

    public string Name { get; set; }

    private class FooEqImpl : EqImpl<Foo>
    {
        public override bool Equals(Foo a, Foo b)
        {
            return a.Name == b.Name;
        }
    }
}

Finally, let’s see how to actually consume our Eq ‘type class’

public void Compare<T>(T a, T b)
    where T : IEq
{
    if (Eq<T>.Equals(a, b))
        Console.WriteLine("equal :)");
    else
        Console.WriteLine("not equal :(");
}

Thoughts

One thing that was really highlighted for me, and something I’d never really thought about before, was that methods like

void M(IFoo a)

have lost an large amount of the compile-time type information that could have been available to them. To keep that information we can write

void M<T>(T a) where T : IFoo

which is likely almost exactly what we’d do if we needed T : IFoo and T : IBar; although given how much more verbose and clunky it is to write code like this, it’s fairly clear (a) why we don’t and (b) that it’s probably not idiomatic.


The more you know…

After writing this I discovered this correspondence of type classes using C++ template which shows some similarities to what I was attempting to achieve here using less powerful C# generics. So while all of this is all clearly a terrible idea, at least I feel that I’ve not inherently failed to understand type classes.

Performance anxiety

Given the choice I’d happily avoiding doing almost any UI work at all, but working in a small team means being comfortable working on any part of the stack. I recently had some performance problems in WPF, to which my initial reaction was hands-to-head, head-to-desk, groan; but a problem is a problem and that’s a major part of why I chose a career in programming, so it was time to get investigating.

Background

We have a fairly simple list-detail set up using a Caliburn.Micro conductor, a TreeView for the list and <views:Component cal:Bind.ModelWithoutContext="{Binding}"/> for the detail. We were seeing performance problems when moving between certain items, the UI would hang for perhaps a couple of hundred milliseconds: not long enough to be disastrous, but easily enough to be jarring to the user and to make any transitions far from smooth. My immediate candidate for suspicion was the DataGrid. The problems seemed to only occur when moving to a detail view containing a DataGrid, and my suspicions became more founded when the problem worsened as the detail view contained more than one DataGrid (although strangely it seemed to matter little how much data / how many rows each DataGrid actually contained).

It looked as though my problem was that of re-binding each DataGrid as we moved between items.

Idea

The idea was to keep the view for each item alive and bound – but out-of-sight – rather than either destroying and creating a view instance each time or re-using and re-binding.

Whether this turns out to be the best solution in the longer-term remains to be seen as it’s clear to see that we’ve caused ourselves a memory leak by keeping the view alive for every item ever selected; although for the specifics of it’s current usage this won’t be an issue as the number of items is limited to relatively small number.

Implementation

Create a control with a CurrentItem property binding to the selected item and an ItemTemplate property that will be used to create views for new items, caching and re-using them for items that have already been selected. This doesn’t help the performance the first time that an item is selected, but each subsequent selection is essentially instantaneous and provides a much improved user experience.

It actually turned out relatively easy to implement this – as you can see below – and in our production version we’ve helped eliminate and memory issues by hooking into Caliburn’s Deactivated event (when WasClosed == true) to avoid holding on to unnecessary view instances.

Code

public class ContentHost : ContentControl
{
	#region Fields

	public static readonly DependencyProperty CurrentItemProperty =
		DependencyProperty.Register(
			"CurrentItem", 
			typeof(object), 
			typeof(ContentHost),
			new PropertyMetadata(
				null,
				OnCurrentItemChanged));

	public static readonly DependencyProperty ItemTemplateProperty =
		DependencyProperty.Register(
			"ItemTemplate", 
			typeof(DataTemplate), 
			typeof(ContentHost), 
			new UIPropertyMetadata(null));

	private readonly Grid contentGrid;
	private readonly Dictionary<object, ContentPresenter> items;
	private UIElement currentView;

	#endregion

	#region Constructors

	public ContentHost()
	{
		this.contentGrid = new Grid();
		this.items = new Dictionary<object, ContentPresenter>();
		this.Content = contentGrid;
	}

	#endregion

	#region Properties

	public object CurrentItem
	{
		get { return (object)GetValue(CurrentItemProperty); }
		set { SetValue(CurrentItemProperty, value); }
	}

	public DataTemplate ItemTemplate
	{
		get { return (DataTemplate)GetValue(ItemTemplateProperty); }
		set { SetValue(ItemTemplateProperty, value); }
	}

	#endregion

	#region Methods

	private static void OnCurrentItemChanged(
		object sender,
		DependencyPropertyChangedEventArgs args)
	{
		var contentHost = (ContentHost)sender;

		var newItem = args.NewValue;
		var view = contentHost.EnsureItem(newItem);
		contentHost.SwapCurrentViewFor(view);
	}

	private void SwapCurrentViewFor(ContentPresenter view)
	{
		BringToFront(view);
		SendToBack(currentView);
		currentView = view;
	}

	private ContentPresenter EnsureItem(object currentItem)
	{
		ContentPresenter view;
		if (!items.TryGetValue(currentItem, out view))
		{
			view = new ContentPresenter();
			view.Content = currentItem;
			view.ContentTemplate = ItemTemplate;
			
			contentGrid.Children.Add(view);
			items.Add(currentItem, view);
		}

		return view;
	}

	private void BringToFront(UIElement uiElement)
	{
		uiElement.Visibility = Visibility.Visible;
	}

	private void SendToBack(UIElement uiElement)
	{
		if (uiElement != null)
		{
			uiElement.Visibility = Visibility.Collapsed;
		}
	}

	#endregion
}

Refactoring Cassowary

Now the work begins…
As I mentioned before, my aim is for this codebase to become:

clean, modern, idiomatic, tested

If Refactoring and Working Effectively with Legacy Code have taught me anything, the first step is to get tests in place so that we can “Cover and Modify” and not have to “Edit and Pray”. There are a number of ports of the Cassowary engine out there (Python, JavaScript) and I was able to get a decent amount of tests written very quickly by porting their existing test suites to C#. This left me with a lot of integration / end-to-end tests, but with relatively few unit tests – for those there was no free lunch.

Let’s get typing

After tests, the first item on the agenda was to improve the type-sanity of the code.
It made heavy use of ArrayList and Hashtable (no generics in sight) and had a lot of casting scattered throughout the code. Replacing the above with List<T>, Hashset<T>, and Dictionary<TKey,TValue> would make the code clearer, cleaner, and safer to work with. I’m a big fan of letting the compiler / type system do as much of the work as possible – it’s much less prone to idiocy than me.

foreach (var idiom …

The next change was another relatively straightforward one: be more idiomatic.
For example, in C# foreach loops are more idiomatic than for loops, and certainly more idiomatic that the direct use of IEnumerators that was to be found in the original code! As I mentioned before, this was a port from a Java implementation of Cassowary and you could tell – it felt like Java. Using bool Try...() methods rather than returning null; properties instead of Get... and Set... methods; all changes to make this codebase feel more like C# and to help future developers (including myself) fall into the pit of success.

Change is tough

And I’m not talking about the refactoring… I’m talking about mutability.
The original code had a lot of publicly mutable state, with comments warning that it shouldn’t be modified when x, y, or z – at least there were comments! Some of the very first steps to tackle this were simply making this internal/protected/private, but that was quickly followed up by removing as much inappropriate mutability as possible.

Currently I’m still wrangling with a few spots of unwanted mutability right in the heart of the solver that are turning out to be a little more stubborn than the rest.

Cassowary

From Wikipedia:

Cassowary is an incremental constraint solver that efficiently solves systems of linear equalities and inequalities. Constraints may be either requirements or preferences. Client code specifies the constraints to be maintained, and the solver updates the constrained variables to have values that satisfy the constraints.

As far as I can tell, the Cassowary solver has been in existence for almost 20 years but there is – as yet – no modern, idiomatic .NET port available.

I felt that it was about time to change to that.

On the shoulders of…

There is an existing .NET port of the Cassowary solver, however from its readme:

Cassowary.net [1] is a port of the Cassowary constraint solving toolkit [2] to the .NET platform. It is based on the Java version by Greg J. Badros, which in turn is based on the Smalltalk version by Alan Borning.

A port of a port of a port. Examining the code we find that it appears to have been ported directly/naively from Java, which has resulted in a lot of non-idiomatic code: no use of of generic data structures, direct manipulation of enumerators, et cetera. That’s not to say that it’s a bad port, simply one that isn’t written in modern C# (forgiveable since it was written almost 10 years ago); and for me, one that I don’t think I’d particularly enjoy interacting with.

So this is my starting point for creating a clean, modern, idiomatic, tested .NET Cassowary constraint solver.

A fork has been created, now the real work begins…

… and ended (as always) with code

Our requirements from an index-type are fairly minimal…

public interface IIndex
{
	int Value { get; }
}

… and this would be enough for a number of scenarios, although not one particular scenario that I wanted: being able to construct a typed-index from an int. This operation is useful for being able to expose existing properties of an array as their typed equivalent, in particular I wanted to expose the length of the array in each dimension.

public interface IIndex<TIndex> : IIndex
	where TIndex : struct, IIndex<TIndex>
{
        TIndex WithValue(int value);
}

The above is then used in conjunction with the fact that T : struct implies T : new() to essentially gain a T : new(int) constraint by using var t = new T().WithValue(i). I could call this a tweak on the prototype-pattern but at the end of the day it’s a bit of a hack around the type constraints I’m able to achieve with generics.

Due to index types needing to be structs we can’t use inheritance, making implementing an index type a rather tedious and unpleasant copy-paste affair. While this obviously has plenty of disadvantages, it has the benefit that each index type is free to enabled – or not – methods and operations as it sees fit, for example IComparable<>, IEquatable<>, operator overloads, &c. No more than five or six index types will be created, with some having the requirement to be comparable (e.g. yearA < yearB) and others with the requirement to explicitly not be comparable (e.g. simulation – each is fully independent of all others) so I consider the trade-offs being made here to be acceptable.

Implementing the wrappers for arrays was also a rather tedious job as each rank requires a separate implementation with the correct number of type parameters.

public class StrongArray<TValue, TIndex0, TIndex1> : StrongArray
	where TIndex0 : IIndex<TIndex0>
	where TIndex1 : IIndex<TIndex1>
{
	private readonly TValue[,] array;

	public StrongArray(TIndex0 length0, TIndex1 length1)
		: this(new TValue[length0.Value, length1.Value])
	{
	}

	public StrongArray(TValue[,] array)
		: base(array)
	{
		this.array = array;
	}

	public TValue this[TIndex0 index0, TIndex1 index1]
	{
		get { return array[index0.Value, index1.Value]; }
		set { array[index0.Value, index1.Value] = value; }
	}

        public TIndex0 Length0
        {
            get { return new TIndex0().WithValue(array.GetLength(0)); }
        }

        public TIndex1 Length1
        {
            get { return new TIndex1().WithValue(array.GetLength(1)); }
        }

	public TValue[,] Array
	{
		get { return array; }
	}
}

And, no, I couldn’t think of a better name at the time!

Was it worth it?

Definitely.
For about a day an a half of coding, what Code Metrics tells me is 125 lines of code – with the biggest contributor being a class of helper methods such as Enumerable.Range equivalents – and a very modest performance penalty, this thin abstraction over arrays has had a significant impact on how much information is conveyed by our code and has helped to reduce the amount of time and effort required to understand a piece of code.

It all started with Matlab…

O, for a green field

We’re currently preparing to rewrite a reasonable amount of Matlab into C#. Starting afresh is always enjoyable but rarely sensible, however one of the major reasons for us doing so is that we no longer have the skills to maintain the codebase as it stands. For a start we no longer have any experienced Matlab developers, and for a second the existing code is a glorious combination of spaghetti logic, single-letter variables, and cryptic – and often untrue – comments.

We intend to do the rewrite in stages, moving into the world of C#, Visual Studio, and heaps of testing and refactoring tools as quickly as possible, then incrementing our way to a reliable, performant, maintainable solution. Our first step will be to rewrite the Matlab code into a very simple stripped-down Matlab-like set of classes in C# as verbatim as possible, we’ll use a barrage of regression tests to make sure that is done correctly. Next, we’ll refactor that code from the loosely-typed ‘framework’ we’ve created into arrays where we know types and dimensions &c; during this process we’ll be familiarising ourselves with the code and adding simple structure as we go. Finally, we’ll convert what we now have into idiomatic C#, moving – where appropriate – away from the array-based Matlab-style approach, using the full power of the language and data-structures available to us.

One of the major struggles that we’ve seen with the current code is tracking dimensions. With an array of simulation * year * ... * series * tranche that is being manipulated and combined with other arrays in sometimes unconvential ways and inside thousand-line methods, it becomes almost impossible to know if the second dimension of arrPenIcrPost was year, simulation, or something else entirely.

With this in mind, I wrote a thin wrapper for C# arrays which, along with some helper classes, will allow for ‘strongly-typed’ indexing: for example having an array of double<Sim,Year>[,] so that the dimensions are not referenced simply by int but by custom types. The types of the dimensions will be an integral part of the type of the object, will be enforced by the language, and will as a consequence be impossible to mistake.

Performance anxiety

My main concern with doing this was that of performance, I truly wasn’t sure how well the code I was writing would be perform. I could certainly see ways in which I hoped the code would be optimised, such as inlining the underlying value of the structs being used as indexes; but I could also see potential problems, mostly around the boxing of value types and the overhead of pointer-chasing.

To my delight (and slight surprise) the performance overhead could be made extremely minimal with relatively little work; the most important factors that I hit while developing were using structs for the index types, avoiding inheritance and virtual methods in certain situations, and using class-level generics rather than method-level generics.
The first is fairly obvious and was the approach I took anyway, I simply changed to classes to see what impact it would have; the second is again relatively straightforward, vtables and all that; the third was slightly more surprising, and I believe has to do with the optimiser being able to avoid boxing value types when accessing them through an interface if the entire class is generic.

There will be code

That’s rather a lot of text without so much as a hint of code. Next time I’ll be looking at the code that actually achieves all of the above!

Ill

Being ill sucks

Last week I was really very ill – something flu-like – and this week I’m slowly recovering from whatever it was. Beside sapping all of my energy it’s also completely messed with my ability to actually think. Because of that, I haven’t really done anything particularly interesting – I’ve been using this time to do all of the boring / monotonous tasks that I’d been putting off – and haven’t had any particularly exciting insights into, well, anything really.

Never too ill for a monad

Since I’ve not really done much, and I’m not feeling up to writing about anything particularly involved, here’s a very simple error monad-like-structure I threw together this week for something I was working on.

public class Exceptional<TValue>
{
	#region Fields

	private readonly TValue value;
	private readonly Exception exception;
	private readonly bool hasResult;

	#endregion

	#region Constructors

	private Exceptional(TValue value)
	{
		this.value = value;
		hasResult = true;
	}

	private Exceptional(Exception exception)
	{
		this.exception = exception;
		hasResult = false;
	}

	#endregion
	
	#region Methods

	public Exceptional<T> Apply<T>(Func<TValue, T> func)
	{
		return UnWrap(
			v => Exceptional<T>.Wrap(() => func(v)),
			ex => new Exceptional<T>(ex));
	}

	public T UnWrap<T>(
		Func<TValue, T> whenResult,
		Func<Exception, T> whenException)
	{
		return hasResult
			? whenResult(value)
			: whenException(exception);
	}

	public static Exceptional<TValue> Wrap(Func<TValue> func)
	{
		try
		{
			return new Exceptional<TValue>(func());
		}
		catch (Exception exception)
		{
			return new Exceptional<TValue>(exception);
		}
	}

	#endregion
}

The brain is a muscle…

So, even though I really wasn’t feeling particularly up to it, I wrote something similar to the above in F#. I’m trying to slowly get a feel for the language after years of OOP indoctrination, and this is (sadly) probably the biggest thing I’ve written in F# so far. I love the concepts behind the language but it can be incredibly frustrating to move from being able to produce clean, concise, idiomatic code in C# to struggling to write even the simplest structures in F#.

type Exceptional<'a> = 
	| Value of 'a
	| Ex of Exception

// (a -> b) -> (a -> Exceptional<b>)
let Bind f = 
	fun a -> 
		try Value(f a) 
		with 
			| ex -> Ex(ex)

let incr x = 
	match x with 
		| 7 -> 	raise (Exception "Seven Eight Nine")
		| _ -> 	x + 1
		
let _incr =  Bind incr

_incr 3 |> Console.WriteLine
_incr 7 |> Console.WriteLine

Await-ing happiness

Introduction

There are currently two main patterns for asynchronous programming in .NET:

  • The ‘original’ asynchronous programming pattern: IAsyncResult, BeginInvoke, and EndInvoke
  • Event asynchronous programming (EAP): a Begin method and a Completed event

Using a Task-based asynchronous pattern has a number of advantages over the above, and in most cases will result in much easier to follow code. However, unless you’re already familiar with the concepts involved, the way it functions will almost certainly be quite different from what you’re used to and to your current mental model of asynchronous work. This means that while I would encourage you to get familiar with the patterns and practices involved, it can take some time working with Tasks to become comfortable with them and to think in their language.

Similar concepts exist in other languages / frameworks and may have more intuitive names, depending on what you believe is in a name: they are often called promises or futures. Linky.

Currently, if you want to offload some work from the main thread of an application, you’re likely to get hold of a background or threadpool thread and start it running. Now you either have no idea when it completes and so no way to return a value, or you have a callback for completion (something like BackgroundWorker). Working like this causes you to split your logic between two methods, one before starting the background work and one after it has completed; in more complex situations it can quickly become difficult to work with your code, to understand the flow of you application, and to reason about concurrency issues.

The basics

Slightly simplistically, a Task or Task represents a method that is in some state of execution, that is it is either about to execute, currently executing, or has already executed. Unlike previous ways of working with asynchronous code in .NET, this allows us to keep hold of a reference to the asynchronously executing code.

So how do you know when your Task has actually completed? You await it:

Task task = FrobnicateAsync();
await task;

This allows us to keep all of our logic in a single method, and makes the flow of our code much easier to follow. In fact the code reads and executes almost exactly the same as if there were nothing asynchronous happening at all; this is the unicorn – making code execute asynchronously without increasing complexity.

// logic before the async work
await FrobnicateAsync();
// logic after the async work completes

Rules to live by

I’m mostly thinking of the WPF world here, but much of the same applies no matter where you are.

Don’t think of async/await as a silver bullet
Like anything, it has it’s quirks and pitfalls but its advantages hugely outweigh these in almost all cases.

Never use async void
With async void you have no Task and so lose your context / reference to the asynchronously executing code and have no way to know when it completes; this puts us back into the ‘old-world’ of asynchronous programming.

… except when the context is already out of your hands
For example void Main() and WPF UI event handlers (`void Button_Click()’ &c) where it was not your code that invoked them in the first place.

Don’t be impatient, always await
Again, if you don’t await a Task, you’ve lost your context to the asynchronously executing code and we’ve gained nothing from using Tasks.

Never call .Wait() or .Result
This is more applicable to WPF as doing so is likely to cause a deadlock when done on the UI thread, but actually applies more widely. While these methods exist for good reason, calling them should be extremely rare, as this breaks the next rule…

Don’t mix and match
It is a seriously bad idea to just throw Tasks into the middle of an existing application hoping it will solve all of your problems, it’s more likely to cause unexpected behaviour than it is to actually solve anything. It’s often significantly simpler to introduce async ‘top-down’; that is, making your entry-points async (Button_Click &c) and spreading async down into your application from there. Other approaches inevitably lead to either async void or calls to .Result and the problems mentioned above.

await GetConclusionAsync();

There are a number of ‘work-arounds’ for various problems that people have had with TPL to be found, however I find that more often than not these are solutions not to problems in the framework but to problems caused by the misuse of it. Now, I’m not saying that there are no hard parts, but if you take the time to grok the TPL and get a feel for it, then you’ll encounter far fewer ‘problems’ with it.

Put in the time and respect it deserves and I promise, you’ll love it.

How do you call it?

Where we’re at

Following on from last time, we have our MethodInfo object and now need to actually invoke it. However we want to do this in a way that is as clean, safe and performant as possible.

Keeping it simple

We could simply call invoke on the MethodInfo object:

var foo = (Foo)methodInfo.Invoke(fooFactory, new object[] { 42 });

Last week, we put a lot of effort into trying to make what we were doing as safe as possible, so to throw away all the safety on the final hurdle seems rather silly. No type checking on the method’s parameters, an ugly cast of the return value to (Foo), and a fairly serious performance overhead make this solution less than ideal.

A nicer way

We can use System.Linq.Expressions to compile ourselves a Func<int, Foo> representing the method we wish to invoke:

var parameter = Expression.Parameter(typeof (int));
var lambda = Expression.Lambda<Func<int, Foo>>(
	Expression.Call(
		Expression.Constant(fooFactory), 
		methodInfo, 
		parameter),
	parameter);
var getFoo = lambda.Compile();
var foo = getFoo(42);

And this works… almost.

For reasons that I won’t go into deeply here, System.Linq.Expressions doesn’t deal with inheritance; it covers only a subset of language features and inheritance is not one of them. If we’re using an interface or base class for fooFactory then this will fail when we try to construct to Func.

The work around for this restriction is extremely simple though, we make the normal compiler do the work with inheritance by wrapping the call with our own concrete method.

private Foo GetFoo<T>(int id)
	where T : FlagBase
{
	return fooFactory.GetFoo<T>(id);
}

Since we’re now compiling this call to a Func<int, Foo> we can do this ahead of time and store the result, failing fast if anything is wrong and allowing us to invoke it repeatedly while avoiding the performance penalties associated with reflection. This leaves our full code looking like:

public abstract class FlagBase
{
	private readonly Func<int, Foo> getFoo;
	private readonly IFooFactory fooFactory = new FooFactory();
	
	public FlagBase()
	{
		var runtimeType = this.GetType();
		Func<int, Foo> methodGroup = GetFoo<FlagBase>;
		var methodInfo = methodGroup.Method
			.GetGenericMethodDefinition()
			.MakeGenericMethod(runtimeType);
		
		var parameter = Expression.Parameter(typeof (int));
		var lambda = Expression.Lambda<Func<int, Foo>>(
			Expression.Call(
				Expression.Constant(this),
				methodInfo, 
				parameter),
			parameter);
		
		this.getFoo = lambda.Compile();
	}
	
	public void Frobnicate()
	{
		var foo = getFoo(42);
		// ...
	}
	
	private Foo GetFoo<T>(int id)
		where T : FlagBase
	{
		return fooFactory.GetFoo<T>(id);
	}
}

Conclusion

What we were trying to do wasn’t particularly pretty and I certainly wouldn’t want to have to do it regularly, but as I mentioned last week this was about striking a balance between doing this strictly with the appropriate information at compile time, and making our API easier and cleaner to consume. Something like this is very much down to personal preference / style but I’m happy with the compromises that have been made, and with a good suite of tests I’m confident that the behaviour of this ‘hack’ is safe and reliable.

Not enough information to be generic…

This problem arose in a library I was writing last week, there were a number of ways to resolve it, all of them involving some amount of pain / ugliness in the code. The only question was where that pain would be.

The problem

We want to call a generic method with the exact runtime type of the current class.

public class FooFactory
{
	public Foo GetFoo<T>(int id) 
		where T : FlagBase
	{
		// ...
	}
}
public abstract class FlagBase
{
	private void Frobnicate()
	{
		var foo = fooFactory.GetFoo<???>(42);
		// ...
	}
}

So, our goal is to get the runtime type of the class in place of the ???.

The solution

It’s relatively simple to imagine ways we can get the deriving class to provide this information.

Since we’re using inheritance, an abstract method fits the bill:

public abstract class FlagBase
{
	protected abstract Foo GetFoo(FooFactory fooFactory, int id);
}

But now we must override this method in each and every deriving class, must get the type parameter correct each time, and must assume the deriving class is actually calling fooFactory correctly.

Another alternative could be to go for a CRTP pattern:

public abstract class FlagBase {}

public abstract class FlagBase<T> : FlagBase
	where T : FlagBase<T>
{
	private void Frobnicate()
	{
		var foo = fooFactory.GetFoo<T>(42);
		// ...
	}
}

This keeps the deriving classes clean but there’s a huge caveat, and one that we can’t enforce. If we create a derived class FlagA : FlagBase<FlagA> we can then create FlagB : FlagA. Unfortunately, we now have FlagB : FlagBase<FlagA> and the type parameter is not the actual runtime type of the class! To make this work we would have to restrict the inheritance from FlagBase<T> to be only one level deep, something that we cannot do.

There are other patterns that we can attempt to apply, but none of them allow us to keep the consuming code out of the picture. In this scenario at least, requiring the caller to provide this information is a bad idea:

  • It’s remarkably easy to provide the wrong information.
  • Every extra requirement you make of a consumer is another opportunity for a mistake.
  • It simply makes the library harder to consume.

Sometimes forcing the consumer to do the extra work is just something we have to live with for the type system we’re in, but here there’s a cleaner alternative – for the consumer at least – and a way that we can ‘internalise’ the pain.

What’s left in the toolbag?

this.GetType() and reflection to the rescue!
Not a sentence you often want to hear…

Searching Google or StackOverflow for anything reflection-based invariably leads to suggestions of invoking the required object by name and, particularly if you’re not very familiar with C#, it can be easy to be led down the garden path. In my opinion (and experience) hard coded object names scream of refactoring pain in the future. While any mistake should be picked up in your test suite, you want to strive to make refactoring as easy as possible, and why have a strongly typed language and a compiler if you’re not going to make them do at least some of the leg work?

For what we’re trying to achieve here, I prefer to get hold of a ‘strongly typed’ method group then change the generic type of that reference. It avoids strings and if applied carefully can be done safely.

public abstract class FlagBase
{
	private void Frobnicate()
	{
		var runtimeType = this.GetType();
		Func<int, Foo> methodGroup = fooFactory.GetFoo<FlagBase>;
		var methodInfo = methodGroup.Method
			.GetGenericMethodDefinition()
			.MakeGenericMethod(runtimeType);
		
		//var foo = fooFactory.GetFoo<???>(42);
		// ...
	}
}

The main type safety (yes, I’m using that term fast-and-loose) mistake we can make here is supplying the type parameters incorrectly, either the wrong number or types that don’t satisfy any type constraints. Fortunately, having the reference to the method right next to us in code helps identify the former at a glance. Satisfying T : FlagBase is guaranteed here, as we’re doing this work inside FlagBase and the runtime type of the object clearly satisfies the constraint.

Now we’re one step further along: we have a reference to the correctly-generically-typed method we want to call. But how do we actually go about calling it?

Using what we’ve built

We could simply call invoke on the MethodInfo object.

var foo = (Foo)methodInfo.Invoke(fooFactory, new object[] { 42 });

This leads to questions of type safety of the method’s parameters and any return value, as well as concerns about performance. Also, there’s only so much safety that I’m willing to throw away to make a library easier to consume.

The answer lies in System.Linq.Expressions for help in compiling this reference to something safely callable. Unfortunately for us, that has its own pitfalls to overcome…