Using wrappers to aid unit testing

As I alluded to about recently when blogging about JustMock, one of the most important attributes of unit tests has to be that they are readable; you can easily reason about them and see what they do.

I also talking about Moq’s overly cumbersome and verbose approach to performing Setups on mocks – I rarely supply arguments for setup methods on mocks, since this would be doing two tests in one i.e. mocking that we handling the result of the method, but also implicitly testing that we called the method with the correct arguments. The latter should be left for another test.

Coincidentally, I had a look at a few other frameworks recently: –

• FSUnit, which is an F# unit testing framework that wraps around NUnit / MSTest / XUnit etc. to provide a more succinct unit test experience in F#
• Simple.Data, which is an awesome data access layer that works over multiple data sources and uses C#’s dynamic feature to allow you to very easily generate queries etc. against data sources with the minimum of fuss.

Simplifying Moq’s Setup

This got me thinking – could we not do the same with mocking frameworks? Well, a couple of hours later, the answer is yes. Here’s a simple example of how you can set up mocks in Moq much more succinctly using a dynamic wrapper class. First the original Moq Setup method: -

[Fact]
public void Foo_GotPayroll_LogsIt()
{
    SetupClassUnderTest();
    service.Setup(svc => svc.GetPayroll(It.IsAny<Person>(), It.IsAny<Person>(), It.IsAny<Person>())).Returns("ABCDEFG");

    // Act
    classUnderTest.Foo(null, null, null);

    // Assert
    logger.Verify(l => l.Log("Got back ABCDEFG."));
}

Notice the large amount of noise from the It.IsAny<T>() calls – almost 50% of the contents of the statement are taken up by It.IsAny().

Now look at this version: -

[Fact]
public void TestFoo()
{
    SetupClassUnderTest();
    service.Setup().GetPayroll().Returns("ABCDEFG");

    // Act
    classUnderTest.Foo(null, null, null);

    // Assert
    logger.Verify(l => l.Log("Got back ABCDEFG."));
}

It uses an new extension method of Setup which operates slightly differently: -

1. It returns a dynamic object which when called immediately seeks out any method on the mock service that are called “GetPayroll”.
2. It then filters out any overloads that do not have the matching return type of System.String.
3. Then, for each matched method, it parses the argument list and generates an expression which calls the method, with an appropriate It.IsAny<T>() call for every argument.

In effect, it expands into the code of the first version, but at runtime. Notice how much more succinct the code is – you don’t need to waste time with It.IsAny<T>(), or call IgnoreArguments(), or even with the lambda expression – you simply provide the name of the method you want to mock out as a parameterless method call – which is what your intent is anyway – and then call Returns on it.

You can also do the same with Throws, which will take in an Exception and setup a Moq call to .Throws(). Easy.

Conclusion

This was more an experiment to see how easy it would be to create a more succinct wrapper around Moq (I’ll put the source code up for anyone that wants it) but also to see whether it would actually work from a consumption point of view – does it feel “right” to call a dynamic method which does setup / mocking for you? Can you have confidence in it? I leave that you to to decide

Performance or readability with Expression Trees in C#

I was fumbling around trying to create some expression trees on Friday and was working through some stuff with a colleague of mine (someone who actually knows how to do it better than me!) and I got to thinking about the characteristics of different ways of doing the same things in C# with respect to both runtime performance and readability / ease of development.

Let’s say we have the following type hierarchy:

Easy enough. Now we want, for some arbitrary reason, to write a generic method that will set a specific integer property to the value of 25, but we don’t know which one it is. In our example above, that could be both the Age of the employee, or the AddressId. You could do this with reflection: -

Expression Trees

Nice. This works well, no problems whatsoever. There is another, strongly typed way of doing it though, with expression trees. By passing in an expression tree that navigates to that property, we can, at runtime, construct a Action method specific to what we want, and then call that method as needed. Here’s how we would consume such a method: -

ageSetter and addressIdSetter are two delegates that we are constructing at runtime to perform the task of setting the appropriate property to the value of 25. The main benefit of such an approach is obvious i.e. strong typing. But there’s another, more subtle benefit of such an approach – performance. To understand why this is, we need to understand how this method is implemented.

CreatePropertySetter returns an Action<T> which, when called, will set the appropriate property to 25: (I’ve elided the GetMembersEnumerator method for clarity)

To make it a bit easier to see what happens, when we call the method with e => e.Age, here’s what the above method looks like with debugger quickwatches pinned: -

By compiling the final expression, we get a proper Action method which is the same as instance => instance.Age = 25, except we’ve constructed this code, at runtime.

I find Expression Trees difficult to get my head around. I understand the idea of them – essentially building up a tree of things like “assign property” and “call method” and “if” etc. which can then be compiled into a lambda. But the Expression API has lots of factory methods and many ways to do the same thing; I guess with time you gain familiarity with the API, but it’s definitely not the easiest thing in the world to get your head around. Worse still, look at the code required to do the same thing as that reflection code – much more effort and much less readable.

However, where performance is concerned, Expression Trees will beat Reflection by miles – as long as you cache the Action method that is generated! The construction and parsing of the expression trees required to create the Action is an expensive operation, so you should cache the Actions. Once you’ve done that, the cost is extremely low, as you are simply calling an action method, almost the same as if you had written it yourself. For example, to set both the Age and AddressId properties to 25, for 2.5 million Employees, I observed the following timings: -

Type of code applied	Time required (ms)
Direct assignment	144
Reflection	3,881
Expression Trees	349
Dynamic	597
Hard-coded lambdas	136

Obviously the other three options wouldn’t be appropriate for the problem at hand (generic property assignment) but I wanted to illustrate how these two mechanisms performed. By the way – notice how much quicker dynamic is than reflection (and these timings were obtained when caching the property info objects as well). Funnily enough, if I wrote hard coded lambdas e.g. instance => instance.Age = 25 and used them, they outperformed code like instance.Age = 25. Why?

Conclusion

When you next use reflection for some property assignments or method calls, think about using Expression Trees, particularly where performance is a factor. Expression Trees are time consuming to write and understand, but offer superior performance and can be consumed in a strongly-typed manner. Alternatively, consider the use of dynamic where possible – again, for property setters and getters and method calls it offers better performance than reflection, and whilst obviously not strongly-typed, the code is again far more readable.

When to use C#’s dynamic type?

The scenario

You have a set of large set (say 250) of classes. You know that all those classes have a common public property on them – let’s say Id, which is an integer. Currently none of these types have any common base class, nor do they have any common interfaces. The classes are code-generated and you cannot modify them; however they are partial so you can add interfaces to them. You already have good code coverage of the rest of your system and are expected to write unit tests around any code you write.

The challenge

You need to write a method called Print that will be provided with a load of objects – say, 10,000 of them – and print their Id to the Console. This routine will be run as a batch task so performance is not an issue.

The solution

Do you: -

a) Create an interface called IIdentifiable, with a single int getter called Id. Painstakingly go through all 250 of your entities, create partial versions of them and manually put the interface on them. Writing unit tests as you go in the standard TDD approach, you code your Print method. You ensure that you only take in IEnumerable<IIdentifiable>, so you can simply iterate over the collection.

Sure, creating the interface and creating those 250 partial files might take a few hours and increase the number of files in the solution, but making the routine type-safe is the right thing to do.

OR

b) Don’t bother with an interface – the Print method will take in IEnumerable<dynamic>. You simply pass in whatever objects you want to print out. You write a set of unit tests around the callers to that method to give you confidence that you won’t ever call the method with types that don’t have Id. As you don’t have to modify the partial classes, the method only takes about twenty minutes to code including your unit tests.

Why bother with all that faffing around with an interface for a single property when we own the code and know when we call it? Doing it this way gets the job done much quicker so I can get on with coding other features in the system.

The conclusion

Which solution would you go for? Is using dynamic here “cheating”? Is it risky? Does it indicate a bad design of your class hierarchy? Or does it indicate a willingness to pick the right tool for the job? Would it save the client that’s paying you any money? Do you care?

Discuss.

Another example of using C# 4 dynamic typing

Here’s a good example of where using Dynamic is handy. Imagine I want to write an all-purpose Excel reader in .NET. This reader class should be able to take in a filename and return me an object which I can use to get data out of the spreadsheet. In itself, that’s not overly difficult using e.g. OLE DB to read from the spreadsheet, but there’s always some boiler-plate involved in creating a .net object to hold the result of the query (unless you want to use DataTables throughout your application), which means you have to create a class to hold the result, and a translator of some sort to go from a DataTable to that object.

Enter the DynamicDataRow object. This handy object sits on top of a standard DataRow but allows dynamic property (column) access at runtime. You can consume it very easily: -

Obviously, we know that the shape of the data will change depending on the spreadsheet content – but don’t want the actual ExcelReader code to change with different spreadsheets.

The ExcelReader.LoadDocument code itself is very plain – it just does some simple OLE DB connection work to read the data into a bog-standard DataSet, and then returns an ExcelDocument object which takes in the DataTable containing the spreadsheet data and populates the Rows property with a DynamicDataRow object for each row in the Table. Notice that so far I’ve not discussed anything C#4 specific yet – just plain OLE DB and some properties setters etc.

In fact, the only bit of C#4 is what we enumerate over i.e. where I have “dynamic row in document.Rows”. In this case, “row” is an object of type DynamicDataRow. This is a simple class which wraps around a normal DataRow but allows direct access to properties instead of the somewhat ugly column indexer notation that you get with a DataRow: -

It’s a tiny class. All it does is inherit from DynamicObject and override the TryGetMember method to remove the need for indexer accessors and replace them with property accessors, so instead of row[“MyColumn”] you can now just do row.MyColumn. Again, though, from a client point of view, this is very easy to consume – look at the first code sample and realise that that will work for any spreadsheet whatsoever. Also notice how we treat “row” as dynamic, rather than DynamicDataRow (or object), as we want the property accessors to get intercepted by the TryGetMember method…

Can’t wait for C#4…

Following on from my posts on dynamic typing… this week I wrote a quick app to import some data from a load of XML files to a load of tables in a SQL database. The columns in the tables and the attributes in the xml file have a 1:1 mapping.

So I firstly wrote some code which goes through a given table and reads the schema from the database and creates a C# type based on the schema (using sp_columns). Then I placed a ColumnAttribute on each column etc. etc., and then goes through the task of iterating through the XML data and creating objects of that new type, copy the data across (doing the odd data type conversion along the way), and finally use the standard LinqToSql DataContext to insert the data into the DB.

But a lot of the code was somewhat ugly – messing about with TypeBuilders and FieldBuilders and the like – I’m sure that I could have done something much more elegant in C#4…. none of it was compile-time safe, it was all using reflection etc..

But it did work great anyway – apparently was used to migrate a good few thousand records of XML data into SQL relatively quickly

A Dynamic XML Document – Part 2

Continuing on from last post, how do we get the array-style [notation] on a dynamic object? Well, there’s a handy method that you can override on DynamicObject called TryGetIndex which does just that:

 

   1: /// <summary>

   2: /// Searches for any elements that have any attribute with the value specified.

   3: /// </summary>

   4: /// <param name="binder"></param>

   5: /// <param name="indexes"></param>

   6: /// <param name="result"></param>

   7: /// <returns></returns>

   8: public override bool TryGetIndex (GetIndexBinder binder, object[] indexes, out object result)

   9: {

  10:     var valueToSearchFor = indexes[0].ToString();

  11:     var matchingItems = GetElementsByAttributeValue (valueToSearchFor);

  12:     if (matchingItems.Any ())

  13:     {

  14:         result = new DynamicXmlDocument (matchingItems);

  15:         return true;

  16:     }

  17:  

  18:     result = null;

  19:     return false;

  20: }

  21:  

  22: private IEnumerable<XElement> GetElementsByAttributeValue (string attributeValue)

  23: {

  24:     var matchingItems = elements.Where (e => e.Attributes ().Any (att => att.Value == attributeValue));

  25:     return matchingItems;

  26: }

 

Here, I’m searching for any elements that have any attributes with a value as per specified, and then setting the result to a new dynamic xml document based on that sequence.

That’s really it, to be honest! The only things left are the Value getter, which just returns the value of the first element in the dxd, and the implementations of IEnumerable and IEnumerable <T>: -

   1: /// <summary>

   2: /// Gets the contents of the first element in this document.

   3: /// </summary>

   4: public string Value

   5: {

   6:     get { return elements.First ().Value; }

   7: }

   8:  

   9: IEnumerator<DynamicXmlDocument> IEnumerable<DynamicXmlDocument>.GetEnumerator ()

  10: {

  11:     foreach (var element in this.elements)

  12:         yield return new DynamicXmlDocument (element);

  13: }

  14:  

  15: IEnumerator IEnumerable.GetEnumerator ()

  16: {

  17:     foreach (var element in this.elements)

  18:         yield return new DynamicXmlDocument (element);

  19: }

 

I’m not that used to using the yield keyword – to be honest most collections I use day-to-day are the in-built IEnumerable<T> ones, but I see how it’s being used above (this bit is basically taken from here.

Anyway… the point being that with a relatively little amount of effort we have an object which can navigate an XML document very easily and more readably than old-style XML access, and with no real loss of type safety compared to those technologies, either.

Dynamic typing with C#4.0 part 2 – A Dynamic XML Document

Here’s a great example of where dynamic typing makes your code much more readable and logical: parsing an xml document. It turns out that someone has already done this – and I nicked a bit of his code (basically the implementation of IEnumerable) – but it’s funny how similar both of our code was before I found it (link is at end of this post).

Here’s an example XML document:

<catalog>

    <book id="bk101">

        <author>Gambardella, Matthew</author>

        <title>XML Developer's Guide</title>

        <genre>Computer</genre>

        <price>44.95</price>

        <publish_date>2000-10-01</publish_date>

        <description>

            An in-depth look at creating applications

            with XML.

        </description>

    </book>

    <!-- etc. etc. -->

</catalog>

Now, to parse that document, you could currently use either good old XmlDocument (and / or XmlReader), or the more modern XDocument in Linq to Xml. However, both of them and still inherently weakly typed, using strings passed into methods such as “Attribute (“MyAttr”) or Element (“MyElement”). I did see an alpha demo of a strongly-typed version of a Xml Document reader a while ago but haven’t heard anything of that recently. I recall seeing that VB9 also has some good XML support, but I’m exclusively a C# coder so let’s concentrate on that

Anyway. So let’s see if we can make an XML document class in C#4 which will let us read the above XML document like this:

   1: // Create our dynamic XML document based off a Linq-to-Xml XElement.

   2: var xDocument = XDocument.Load ("Example.xml");

   3: dynamic dynamicXmlDocument = new DynamicXmlDocument (xDocument.Root);

   4:  

   5: // Get the first five books

   6: var books = dynamicXmlDocument.book as IEnumerable<DynamicXmlDocument>;

   7: foreach (dynamic book in books.Take (5))

   8: {

   9:     // Print out details on each book

  10:     System.Console.WriteLine ("Id: {0}, Title: {1}, Price: {2}",

  11:         book.id,            // Attribute access

  12:         book.title.Value,    // Element access

  13:         book.price.Value);  // Element access

  14: }

  15:  

  16: // Get a specific book

  17: var specificBook = dynamicXmlDocument.book["bk107"];

  18: System.Console.WriteLine ("Id: {0}, Title: {1}", specificBook.id, specificBook.title.Value); 

  19:  

  20: System.Console.Read ();

This actually wasn’t that difficult to write! Again, inheriting from DynamicObject and overriding a couple of methods, I was able to get this done in about three quarters of an hour.

First thing is the class hierarchy, our constructors and single member field:

   1: class DynamicXmlDocument : DynamicObject, IEnumerable, IEnumerable <DynamicXmlDocument>

   2: {

   3:     IEnumerable <XElement> elements;

   4:  

   5:     /// <summary>

   6:     /// Creates a new instance of the XML Dynamic Document based on a single XElement.

   7:     /// </summary>

   8:     /// <param name="element"></param>

   9:     public DynamicXmlDocument (XElement element)

  10:     {

  11:         elements = new List<XElement> { element };

  12:     }

  13:  

  14:     /// <summary>

  15:     /// Creates a new instance of the XML Dynamic Document based on a sequence of XElements.

  16:     /// </summary>

  17:     /// <param name="elements"></param>

  18:     public DynamicXmlDocument (IEnumerable <XElement> elements)

  19:     {

  20:         this.elements = new List<XElement> (elements);

  21:     }

Nothing too scary there, but notice how we implement IEnumerable and IEnumerable<T> so that we can do the foreach and .Take (5) in the original example.

 

The next bit is the first DynamicObject method we override, which gets called every time you make a property accessor request e.g. myDynamicDocument.book. The method looks for all sub-elements that match the parameter name, and if it finds at least one, returns a new dynamic xml document (dxd) based on them. If not, it looks for any attributes in the first element of the current dxd and returns the value if it finds that. Otherwise it returns null.

 

   1: /// <summary>

   2: /// Gets either all children the XML Dynamic Documents (i.e. elements), or the current element's attribute.

   3: /// </summary>

   4: /// <param name="binder">Specifies the keyword to search on.</param>

   5: /// <param name="result">The resultant object.</param>

   6: /// <returns>True is a match was made.</returns>

   7: public override bool TryGetMember (System.Dynamic.GetMemberBinder binder, out object result)

   8: {

   9:     var elementNameToSearchFor = binder.Name;

  10:     var matchingChildElements = elements.Elements (elementNameToSearchFor);

  11:     if (matchingChildElements.Any())

  12:     {

  13:         result = new DynamicXmlDocument (matchingChildElements);

  14:         return true;

  15:     }

  16:  

  17:     var attributeNameToSearchFor = binder.Name;

  18:     var attribute = elements.First ().Attribute (attributeNameToSearchFor);

  19:     if (attribute != null)

  20:     {

  21:         result = attribute.Value;

  22:         return true;

  23:     }

  24:  

  25:     result = null;

  26:     return false;

  27: }

 

The next question is how to get that array notation e.g. book[“123”] as per the example? That’ll be answered in the next post!

Dynamic typing with C#4.0

I’m sure I saw a video of Anders Heijlsberg doing something like this but anyway, I knocked this up in about five minutes and it’s well smart!

This is an example of what you can do in C#4.0 with dynamic:

   1: dynamic bag = new DynamicBag ();

   2:  

   3: // Assign the value "Isaac" to property "Test" on bag, then write it out.

   4: bag.Test = "Isaac";

   5: System.Console.WriteLine (bag.Test);

   6:  

   7: // Create an anonymous type and place into Stuff, then print out the Age

   8: bag.Stuff = new { Name = "Isaac Abraham", Age = 29, City = "London" };

   9: System.Console.WriteLine (bag.Stuff.Age);

What’s cool is that bag has no such property at compile time called Test or Stuff. And even if they did, “Stuff” couldn’t be of the type that gets assigned to it as that type is generated anonymously.

So how do you do this? I was looking through wikipedia on C#4.0, having seen a nice video on Channel 9 on the language, and saw the following sentence:

Dynamic lookup is performed using three distinct mechanisms: COM IDispatch for COM objects, IDynamicObject DLR interface for objects implementing that interface, and Reflection for all other objects. Any C# class can therefore intercept dynamic calls on its instances by implementing IDynamicObject.

So, I opened up VS2010, created a class and tried to inherit from DynamicObject. At first I got nowhere, and couldn’t even find the Microsoft.CSharp assembly to reference, until I realised that for some reason VS2010 had started my project targeting .NET 3.5 instead of 4.0. Having fixed this, I was able to quickly knock up my dynamic property bag class:

   1: class DynamicBag : DynamicObject

   2: {

   3:     Dictionary<string, object> PropertyBag = new Dictionary<string, object> ();

   4:  

   5:     public override bool TrySetMember (SetMemberBinder binder, object value)

   6:     {

   7:         if (PropertyBag.ContainsKey (binder.Name))

   8:             PropertyBag[binder.Name] = value;

   9:         else

  10:             PropertyBag.Add (binder.Name, value);

  11:  

  12:         return true;

  13:     }

  14:  

  15:     public override bool TryGetMember (GetMemberBinder binder, out object result)

  16:     {

  17:         if (PropertyBag.ContainsKey (binder.Name))

  18:         {

  19:             result = PropertyBag[binder.Name];

  20:             return true;

  21:         }

  22:  

  23:         result = null;

  24:         return false;

  25:     }

  26: }

So what happens when we try to access a property on dynamic? Well, my (hugely limited understanding) is that the C# runtime binder first sees if it can resolve the property request itself. If it can’t (as in our case), it then asks the DLR to see if it can do it. So the DLR sees if the object implements DynamicObject, and if it does, it then calls one of the above methods TrySetMember and TryGetMember.

And it just works! I’m still not entirely sure of the times when we should and shouldn’t use this. But it’s quite cool to see nonetheless

VS2010 Professional Review Part 2 – Dynamic Typing in C#4.0

Visual Studio 2010 comes with the next version of C# – version 4.0. The most controversial feature of this version seems to be the dynamic typing features that are built on top of the DLR (also part of the .NET 4). No, that’s not the Docklands Light Railway – it’s actually the Dynamic Language Runtime. The DLR is a new layer that sits on top of the Common Language Runtime (CLR) in .NET and provides some of the sorts of features available in existing dynamic languages (Python, Ruby) in existing CLR languages such as C# and VB as well as some of the newer .NET languages that are appearing.

My (hugely limited) understanding of dynamic language are that they are primarily weakly typed languages i.e. little or no compile-time checking that e.g. you are accessing properties that exist or not etc.. Think how in JavaScript you can simply do something like assign a value to a property without having explicitly declared that property first etc.. In some languages, like Ruby, this is a fundamental part of the language and you can do things in those languages that look positively weird to a C# coder the first time you see them.

So, what is dynamic typing in the C# sense? Something like this (albeit a contrived example, as usual). Here are two classes, Employee and Person. They have nothing in relation in terms of class hierarchies:

class Employee
{
    public string Name { get; set; }
    public int Age { get; set; }
    public string Department { get; set; }
}

class Person
{
    public string Name { get; set; }
    public Gender Gender { get; set; }
    public int Age { get; set; }
}

Suppose we wanted to print to the Console the Name and Age of all Persons and all Employees. We would probably write two methods which takes in either an Employee or a Person, which would print the Name and Age of either a Person or an Employee and let the compiler choose which method to call depending on the type of object we’re dealing with. Or we might have a single method which does an if / then statement on the type (ugly . Or maybe we’d have a single method which used reflection to get the two common properties out of these types and print the details:

 

static void PrintDetails(object detailsContainer)
{
    object Name = detailsContainer.GetType().GetProperty ("Name").GetValue (detailsContainer, null);
    object Age = detailsContainer.GetType().GetProperty("Age").GetValue(detailsContainer, null);

    System.Console.WriteLine("{0} is {1} years old.", Name, Age);
}

Obviously, this is weakly typed – we’re passing in objects. At first glance, this is completely against what most C# coders have been taught to do. But consider – in some ways this is nicer than e.g. having two separate methods which do 99% the same thing – it’s easier to see what’s going on i.e. a single method which prints out the details of the object to the console rather than two methods which at first glance do the same thing. But the problems are: -

1. Weak typing. Let’s leave this discussion for later on…
2. The syntax to get the properties is ugly. Let’s deal with this now

Reflection is Ugly!

Using reflection to get the value of a property isn’t hard to do in .NET, but it is a little strange to look at.

1. Get the Type of the object you want to interrogate e.g. MyObject.GetType ();
2. Get the PropertyInfo of the Property that you want e.g. MyType.GetProperty (“ThePropertyIWant");
3. Get the Value from the PropertyInfo given a particular object of that type e.g. MyProperty.GetValue (MyObject, null);

So that’s a chain of three method calls to get any given property – at a glance, it’s all a bit "weird” to see what’s going on.

Here’s how we would write the same PrintDetails method in C# using Dynamic typing:

static void PrintDetails(dynamic detailsContainer)
{
    System.Console.WriteLine("{0} is {1} years old.", detailsContainer.Name, detailsContainer.Age);
}

The main difference is the use of the “dynamic” type instead of “object” as the type of the method parameter. “dynamic” is a new type in C# which is in reality just plain old object. But it tells the compiler to not check any method invocations or property accessors until runtime, I presume using reflection (and you therefore get no intellisense when manipulating dynamic objects). So it’s no more or less weakly type than the reflection-based example, just a whole lot easier to read.

You can cast any type as Dynamic and then do what you want with it – but you can of course get this “wrong” e.g. if I called a property or method that did not exist, I’d get a runtime error – just like you would with reflection (Mike Taulty has a good blog posting about resolution of overloaded methods using dynamic types and overloads).

And just to clarify – dynamic is NOT the same as var! Dynamic is a 100% weakly typed object, you don’t even get the Object methods like ToString() and GetType on them (which every type has). Var is a always strongly typed object, even if it’s an anonymous type.

Static versus Dynamic Typing

Coming from a C# or C++ background, you might be wondering “why do we want features like this? Isn’t statically typing better than dynamic typing?”. Well, the impression I get from some of the interviews with people involved in the development and evolution of .NET is that they see C# and VB .NET becoming more of a hybrid language in the future, offering “best of breed” features from static and dynamic languages, just as in C# 3 they took declarative features from e.g. SQL which became LINQ and merged them with imperative language features like for loops.

So, I think the answer to “is dynamic typing a good thing” is something like “yes, in its right place”. I wouldn’t expect us to chuck interfaces and class hierarchies etc. out of the window just because we can – but dynamic typing can be used in a few places in C# to make our lives a lot easier (and more readable!). Here are some examples: -

• Making code more readable by hiding Reflection. Talking of reflection, a lot of the time (always?) you will be able to avoid using reflection-style calls to get properties and methods and simply use the dynamic features in C# 4 instead.
• Interacting with dynamic languages. You can already have C# and VB .NET classes talk to one another, because they are both built on .NET. However, there are now some languages cropping up in the .NET world such as IronPython and IronRuby (I think?) which are .NET versions of Python and Ruby. So, in order to interact from the C# world with .NET assemblies written in those languages, you need to have support for dynamic typing in C#.
• Talking to COM libraries. There are some great examples on the Internet showing how much easier it is to interact with COM methods using dynamic typing than using Reflection. If you’ve ever done COM interop, such as Excel or Word document manipulation, you’ll know that this is a nightmare – using the dynamic keyword makes your code a lot more readable! This is also especially useful when interacting with e.g. JavaScript in Silverlight.

However, there’s also a risk that people stop using "proper” static typing concepts such as interfaces and class hierarchies etc. simply because they cannot be bothered with it and using dynamic is “easier”. I’m not saying that this approach is something out of the “dark side” – I’m sure that there are times where it’ll be a real timesaver. And, provided you’re doing lots of good unit tests, you can probably get away with dynamic typing when required – but it’s not an excuse for breaking OO rules!

If you want to find out more about dynamic, there are some decent videos on Channel9 and MSDN – there’s one in particular by Anders Heijlsberg who goes through the feature in great depth – worth checking out.