That means I am a C# MVP, and I am very proud of it!

I feel it is important for me to contribute to, and learn from, the technical communities around the world, and therefore I’m honored by receiving this award for my contributions. I will do my best to continue to contribute to the communities in the time to come, and I know I will learn a lot from them.

- Tore Vestues

There are many ways to use reflection, and the performance on them vary a lot. What we did was to try out every method and timing them to measure performance. These are the methods we tested: Normal property access, normal reflection, compiling and invoking a compiled expression, using Emit to create, compile and run the statement.

Normal property access

To compare the other methods, we measured the performance on accessing a property the normal way:

1

Run("Normal property access", () => { var city = address.City; });

It was no surprise that this was the fastest method.

Normal reflection (250 times slower than normal property access)

1
2

var cityPropertyInfo = typeof (Address).GetProperty("City");
Run("With reflection", () => cityPropertyInfo.GetValue(address, new object[0]));

This is what most of us think about when talking about reflection. This is also the by far most common method of reflection used in Glue. Although about 250 times slower than normal property access, this method has very strong sides compared to the other methods.

Invoking compiled expressions (twice as slow as normal property access)

1
2
3

Expression<Func<Address, string>> expression = x => x.City;
var func = expression.Compile();
Run("Invoke compiled expression", () => func.Invoke(address));

Using compiled expressions is another way of dynamically invoking members on objects. Due to the syntax exposed in the api in Glue, most mapping specifications enter Glue as (uncompiled) expressions. The fact that it is only about twice as slow than normal property access, is very promising. But there is a catch, a big one. In order to invoke this way, the expression must be compiled. It is not compiled when it enters Glue, so we have to include the time it takes to compile the expression as well.

Compile Expression and invoke it (51700 times slower than normal property access)

1
2
3
4
5

RunLong("Compile Expression and invoke", () =>
             {
                 var compiledFunction = expression.Compile();
                 compiledFunction.Invoke(address);
             });

Yes, if you have to compile an expression before invoking it, it takes about 200 times longer to do the operation than with normal reflection. Leaving this a unattractive method to use with Glue.

Using Emit, invoking a compiled expression (4 times slower than normal property access)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

private Func<Address, string> GetEmitDelegate()
{
    var dm = new DynamicMethod("TestMethod", typeof(String), new [] {typeof(Address) }, typeof(Address).Module);
 
    MethodInfo getCity = typeof(Address).GetProperty("City").GetGetMethod();
 
    ILGenerator il = dm.GetILGenerator();
    il.Emit(OpCodes.Ldarg_0);
    il.EmitCall(OpCodes.Call, getCity, null);
    il.Emit(OpCodes.Ret);
 
    return (Func<Address, String>)dm.CreateDelegate(typeof(Func<Address, String>));
}
 
var emitDelegate = GetEmitDelegate();
Run("Emit: run compiled statement", ()=>emitDelegate(address));

My guess is that using Emit is not something you will be doing a lot. But, we had to try. Again, executing a compiled expression was fast. But as with expressions, the problem comes when you have to compile before running.

Using Emit, create statement, compile it and run (39000 times slower than normal property access)

1

RunLong("Emit: Create statement, compile, run",()=>Emit(address));

As we can see, this is also horribly slow.

Conclusion

Unless you can create an expression/emit statement and compile it and then run the compiled version more than 200 times, in the app’s lifetime, using normal reflection is by far the preferred way to go when you have to dynamically invoke members on objects.

- Tore Vestues

Thanks to Åsmund Eldhuset.

Here’s the source

I’m actively developing it. I’m also actively using it. In this post I’ll share my experience as a user of Glue, and how easy it is to set up the mappings using TDD.

The example

We want to create a mapping between DomainPerson and GuiPerson, listed here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class DomainPerson
{
    public int Id { get; private set; }
    public String Name { get; set; }
    public DomainAddress Address { get; set; }
}
 
public class DomainAddress
{
    public String StreetAddress { get; set; }
    public int ZipCode { get; set; }
    public String City { get; set; }
    public String Country { get; set; }
}
 
public class GuiPerson
{
    public int Id { get { return 0;} set { return;} }
    public String Name { get; set; }
    public String StreetAddress { get; set; }
    public int ZipCode { get; set; }
    public String City { get; set; }
    public String Country { get; set; }
}

Making sure all properties are related

What I test first is that all the properties are related (or actively ignored). This makes it easy to later detect changes in the classes we map between. It also makes it easy for us to see what properties we have to handle.

But first, in traditional TDD style, lets start with writing a failing test. The test should verify that all properties on GuiPerson are either related or actively ignored. The test looks like this:

1
2
3
4
5

[Fact]
public void AsserAllPropertiesRelated()
{
	mapping.GetRelationsVerification().AssertAllPropertiesRelated<GuiPerson>();
}

and, as this will not compile, let’s create the actual mapping:

1

mapping = new Mapping<DomainPerson, GuiPerson>();

It compiles, but as expected, it fails. We have created a mapping, but nothing is related. A nice feature with Glue is that it tries to be as informative as possible when it fails. Look at the exception we receive when running this test:

Not all properties are related (or ignored): Id, Name, StreetAddress, ZipCode, City, Country

It tells us what properties we need to handle. This makes my job easy. I’ll just have to relate (or ignore) all the properties reported in the exception:

1
2
3
4
5
6
7

mapping.Relate(domain=>domain.Id,gui=>gui.Id);
mapping.Relate(domain => domain.Name, gui => gui.Name);
 
var addressMapping = new Mapping<DomainAddress, GuiPerson>();
addressMapping.AutoRelateEqualNames();
 
mapping.Flatten(domain=>domain.Address,addressMapping);

Running the test, I get another Exception:

Glue.GlueException : The relation between ‘Id’ and ‘Id’ has atleast one readonly property, and can not be related TwoWays

Ah, fair enough, it went a bit fast there. I related all properties, but I didn’t check if any where readonly. Luckily, Glue tells us this early. I’ll make this change:

1

mapping.RelateTowardsRight(domain => domain.Id, gui => gui.Id);

And when I run the test again, it goes green. Now all properties are related, and we are protected from future changes.

Make sure the mapping actually works

But will it really work? We can also easily check if the actual values can be set on the target object. You should do this. I always do. So, lets start with another test:

1
2
3
4
5

[Fact]
public void AssertMappingWorks()
{
    mapping.GetMapperVerification().AssertMapsCorrectlyTowards(new GuiPerson());
}

Running this test, we get an Exception:

Glue.GlueException : Failed properties: Id (Failed to set value)

Ah, it detected that Id on GuiPerson is totally unable to set. Ok, lets say that this is supposed to be this way. That means we should not map Id towards GuiPerson. That means that we must remove this:

1

mapping.RelateTowardsRight(domain => domain.Id, gui => gui.Id);

Running the tests again makes AssertMappingWorks gets green, but now AsserAllPropertiesRelated got red again. That is because we have not related Id on GuiPerson. But since we do not want to relate it, we ignore it, to signal that we actively have made that choice. We do it like this:

1

mapping.IgnoreTowards<GuiPerson>(gui=>gui.Id);

Running the tests, they both are green, and now we know that we have a working mapping, which also are protected from failing on future changes.

Note that this example only tests the mapping and relations towards GuiPerson, in a bidirectional mapping scenario I advice to write the same two tests towards DomainPerson.

This is how I do it, and it works great for me. Hope you liked it. To learn more about Glue, and to download it, go to the Glue homepage at Codeplex

- Tore Vestues

You’ll find examples and code here: http://glue.codeplex.com

Glue is a general purpose, bidirectional automatic mapping for the .Net platform, with strong verification and testing tools.

I’ve seen quite a lot of less than optimal handling of mapping issues in quite a few projects over the years. Again and again mapping seems to be just a task we have to do, and a bit too small for automating. It becomes clearer and clearer to me that mapping is both an important task in many projects, and it is always a repetitive and boring task. In addition far to often subtle annoying bugs tend to sneak into mapping code. This motivated me to create Glue. And this is what I need from a mapping framework:

a) a way to automate mapping, mostly because it is boring, and that makes it error prone,
b) a way to automatically test the mapping, I’ve found that manual written test code for mapping is seldom done in a good way,
c) a way to prevent future changes making my mappings obsolete. When people make changes, they rarely focus on mapping (and honestly they should not either). They should be told when they have to update the mapping.

Now, you could argue that there is already a mapping framework available on the .Net plattform. And when I started this work, I actually started with that framework, thinking I could just make a few extensions to fulfil my needs. I actually spent some time in the source code to try to implement it, but sadly I realized that our needs differed too much. So, I created Glue, and these where the driving forces:

General purpose

Glue is a general purpose mapper. We realize that in the real world there are a lot of different solutions, and not all of them follow “the one true pattern”. In fact, mapping is often used to map to and from subsystems that are far from well designed. Subsystems we try to hide in a layer because we do not want it to leak into the other layers. Thus, we believe a mapper must support quite a few different scenarios. The goal is to promote good coding practices, but not to ignore the fact that there is a lot of legacy code out there that forces us to work a bit differently at times.

Bidirectional

I would say that in many mapping scenarios we need to map in both directions. First we get data from an object in a layer, and map it to an object in the layer above. When that layer is done with manipulating that object, we often want to map it back to down to the layer where it all came from. I have noticed not all mapping frameworks see it this way, and this was one of the reasons why I started working on Glue instead of trying to extend existing frameworks.

Strong verification and testing tools

I want to be absolutely certain that my mapping works. I also want to make sure that it is very hard to break it later. Manually writing tests for mapping is even more tedious than writing manual mapping. Glue automates this. Future changes has a sad reputation of breaking mapping code. Glue helps you detect this. Tools for helping the mapping is very important to me. And more tools will be available in future releases.

Simplicity

Mapping should be simple. Glue tries to simplify both the mapping process, and the verification and testing. You should not have to state the obvious, and Glue support relating properties automatically based on names.

Explicitness

Although Glue enables you to automate much of the mapping process, it also gives you the opportunity to be explicit about the mapping. So if you want to describe every relation in detail, you can. When it comes to understandable code this can be a good thing. Taking difficult to understand implicit mappings, and stating them explicitly can sometimes make things much easier to understand.

Current version and the future

The current version is 0.2.0 Alpha. It is still in Alpha because if we find good ways to improve the API, we do not want to lock ourselves to it just yet, before we get more feedback. I’m guessing the next release will be Beta.

I am currently using Glue on the project I am working on, and in about a month it will reach production. This somewhat guarantees that it will continue to evolve as our needs expand, and that we will find bugs sooner, and they will be fixed sooner.

Looking into the future we have some exciting ideas on tools to help with the mapping, and we are also working hard to make Glue as easy as possible to use, so expect simplifications. In addition we want Glue to serve a broad set of needs, so feedback is highly appreciated and if you explain your special needs, we might just implement it.

You’ll find examples and code here: http://glue.codeplex.com

- Tore Vestues

In my last project we used the ASP.NET MVC framework along with StructureMap, which made us create our own controller factory. I just blogged about it here.

If it was a good design decision or not I am not completely certain anymore, but we added some more framework logic to the controller factory, including checking state on the HttpRequest-object. This, it turned out, was a path to trouble. After a while we had unexpected behavior in our system, sometimes it leaked information between HttpRequests it seemed! But since this only happened during stress testing, it was hard to find the cause.

What we found was that the RequestContext.HttpContext-object was not all the way thread safe. When a request hits our custom controller, and the request goes to sleep to serve another request, the HttpContext of the factory changes to the second requests HttpContext. This means that the first request will work on the second requests HttpContext when it wakes up. This is bad news if you are dependent on the HttpContext in your custom controller factory.

The lesson is this: you have to do at least one of the two actions below if you want to access the HttpContext in your custom controller factory.

1)

The problem occurs when you set your controller factory like this (normally in the global.asax file)

1

ControllerBuilder.Current.SetControllerFactory(new CustomControllerFactory());

If you send in an instance lik this, it will be the only instance of your controller factory, and this is where the HttpContext-concurrency issues arrive in the first place. What you can do, which will take away all the concurrency issues is to send in the type instead of an instance, like this:

1

ControllerBuilder.Current.SetControllerFactory(typeof(CustomControllerFactory));

The drawback to sending in the type is a) your controller factory will be instantiated for every request and b) you cannot send in anything to your instance (since you’re not instantiating it). This might not be a problem, and if not, you’re good to go.

2)

If you have to use one instance only of your controller factory, and you need to access the HttpContext for a request, you MUST use the HttpContext.Current-instance and not the RequestContext.HttpContext. The HttpContext.Current is as far as I’ve tested thread safe.

Not thread safe:

1

RequestContext.HttpContext

The thread safe alternative:

1

HttpContext.Current

I just found out that this is a bug

- Tore Vestues

The ASP.NET MVC framework has a default controller factory (DefaultControllerFactory) that requires all controllers to have a parameterless constructor. So, if you want to inject your dependencies to the constructor, you can’t do it. In addition, Microsoft suggests the following pattern to mock out the dependencies when testing:

The Microsoft way of testing

(Example from www.asp.net/mvc)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

//The Microsoft way...
public class GroupController : Controller
{
    private IContactManagerService _service;
 
    public GroupController()
    {
        _service = new ContactManagerService(new ModelStateWrapper(this.ModelState));
    }
 
    public GroupController(IContactManagerService service)
    {
        _service = service;
    }
    //...
}

In other words, create one constructor for the actual application, and one constructor for testing. It works, you get to test it, it’s not all that bad, but it just doesn’t sit well with me.

Take control of your controllers!

Don’t you like this either? Well, there is an easy way out of it. One of the really good things about ASP.NET MVC is that it is easy to configure. You can create your own controller factory and take control of the whole process. It might sound like a complex task, but it isn’t.

Let’s start with our controller, it has a dependency that is injected through the constructor:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class HomeController : Controller
{
    private readonly Speaker speaker;
 
    public HomeController(Speaker speaker)
    {
        this.speaker = speaker;
    }
    public ActionResult Index()
    {
        ViewData.Model = speaker;
        return View();
    }
}

Running the website now, trying to reach this controller, will make the framework crash (”No parameterless constructor defined for this object.”). We need our own controller factory to make this work:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class StructureMapControllerFactory : DefaultControllerFactory
{
    private readonly IContainer container;
 
    public StructureMapControllerFactory(IContainer container)
    {
        this.container = container;
    }
 
    protected override IController GetControllerInstance(Type controllerType)
    {
        return (IController)container.GetInstance(controllerType);
    }
}

This controller takes in a StructureMap.IContainer and uses it to create all the controllers. It inherits from the DefaultControllerFactory and overrides the GetControllerInstance-method that is used to create controllers.

Now all we have to do is to tell the ASP.NET MVC framework that it should use our controller factory. To do that simply add this line in the Application_Start() method in the Global.asax file:

1

ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory(new Container()));

(Notice that we do not need to configure StructureMap since our dependencies are so easy to resolve. In a real world app you will most probably need to configure the container)

There you go. Using StructureMap with the ASP.NET MVC framework is easy!

Download the complete example here

-Tore Vestues

One of the nice things (there are several others!) about dynamic languages like Python is that the code feels much cleaner. It is not bloated with type declarations all over. This clean feel was also the goal of the language Boo, and even though it is a static language, Boo really gives you that dynamic feel.

The question is the of course: Is the C# getting more dynamic?

Well to be honest I do not think so. Having to declare a type at all (even if the declaration is “dynamic”) feels quite static, and the code bloats like static languages. Most of the time. I think it is wrong to think that C# is a more dynamic language due to the dynamic keyword, and I feel you are not using the right tools if you try to use C# as a dynamic language. If you want to write dynamic code, use a dynamic language.

But when we get the dynamic keyword, lets find things to use it for. When I am introduced to new features I am not that interested in all the fancy things you can do with it, I want real value. And I think I have found an example of real value in the dynamic keyword. I’ll give you an example, other than in com-interop, where the dynamic keyword will help you keep your code nice and clean, where otherwise you’d have to write a whole lot of ugly code.

The Quick Xml Reader

The funny thing is that I have already implemented a nice xmlreader in Boo (using the IQuackFoo-interface). When the dynamic keyword was introduced in C# 4 and you’ve got the IDynamicObject from the DLR, I figured I can do the exact same thing in C#. That’s just cool!

So what did I do? Here’s the comment from the Boo code file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

class XmlReader(IQuackFu):
"""
Represents an xmldocument using "dynamic typing". 
Can be used to retrieve single values from the xml-document.
There is no support for retrieving lists.
 
Language: 
 Element: Both nodes and leaves
 Node: an element containing sub-elements
 Leaf: An element that represents a value (in xml this is an attribute or a node with nodetype text)
 
use method names to retrieve nodes, and properties to retrieve leaves
example:
<myXml stat="ok">
	<user id="123" nsid="123">
	    <username>Tore</username>
	    <password>foo</password>
	</user>
</myXml>
 
myXml as duck = XmlReader(xmlString)
myXml //will fail since "myXml" is no leaf
myXml() // will return a new XmlReaderrepresenting the rsp-node with children
myXml().stat // will return "ok"
myXml().user().username // will return "Tore"
"""

How cool is that? This is dynamic, resolved at run time, and it can now be done in C# as well. The point with parsing xml is that you won’t catch errors in the xml structure at compile time anyway. So why not just do the code dynamic?

So, our Xml reader let’s you easily get values from an xml structure without having to declare all the types and without having to worry about all the details of the xml-parsing that normally is a bit complex and frankly, boring. In addition the code is much more readable than normal xml-parsing code.

Xml reading in C#

So, how do we do this in C#? Our XmlReader is a class where you can use any method name or property name on it, and it will still compile. For example, This will compile:

1
2

dynamic ourReader = new XmlReader(xmlString);
ourReader.WhateverMethodNameYouLike();

To do this, the XmlReader needs to inherit the IDynamicObject, and it has to implement the method GetMetaObject that returns a MetaObject.

Simplifying the MetaObject

To implement a MetaObject and do some useful stuff you actually have to understand how to build a Linq expression tree that describes the action to be taken. If people are going to use this, it should be as simple as possible. Building Linq expression trees is not as simple as possible IMHO. So, I’ll make a generic base class that hides the whole MetaObject with its Linq expression trees, and let you override some methods in your XmlReader class instead.

I will not go into details on how I have done this, but if you’re interested, you can look at the source (there’s a link at the end). The ‘magic’ is within the MetaBaseDynamicObject. Together with the BaseDynamicObject these can be reused for different tasks that needs on the fly interpreting of property and method calls.

All you have to do is to inherit the BaseDynamicObject, and override any of these methods:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class BaseDynamicObject:IDynamicObject
{
    /// <summary>
    /// If a method on this object is called run time, this method will be called.
    /// </summary>
    /// <param name="action">Information on the method that has been called</param>
    /// <param name="args">parameters on the method call</param>
    /// <returns>The return value for the originally called method</returns>
    public virtual Object Call(CallAction action, object[] args)
 
    /// <summary>
    /// If a property is set on this object run time, this method will be called.
    /// </summary>
    /// <param name="action">Information on the property which value is attemted set</param>
    /// <param name="value">the value that the property is attemted set with</param>    
    public virtual void SetMember(SetMemberAction action, object value)
 
    /// <summary>
    /// If a property is called on this object run time, this method will be called.
    /// </summary>
    /// <param name="action">Information on the property which is being called</param>
    /// <returns>The return value for the property that has been called</returns>
    public virtual Object GetMember(GetMemberAction action) //, MetaObject[] args)
}

Implementing the XmlReader

So what we have to do here is to create a class (XmlReader), inherit the BaseDynamicObject, and override Call and GetMember. We will not bother with SetMember now, as we do not want to support updating the xml. This is what it looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

public class XmlReader:BaseDynamicObject
{
    private readonly XmlElement element;
 
    public XmlReader(string xmlText) {
        var doc = new XmlDocument();
        doc.LoadXml(xmlText);
        element = doc.DocumentElement;
    }
 
    public XmlReader(XmlElement xmlelement)
    {
        element = xmlelement;
    }
 
    public override object Call(CallAction action, object[] args)
    {
        var elements = element.SelectNodes(action.Name);
        if (elements.Count == 0) 
            throw new Exception("Element '" + action.Name + "' doesn't exist in xml");
        if (IsLeaf((XmlElement)elements[0]))
            throw new Exception("Element '" + action.Name + "' is a Leaf and cannot be fetched as a Node");
        return new XmlReader((XmlElement)elements[0]);
    }
 
    public override object GetMember(GetMemberAction action)
    {
        var elements = element.SelectNodes(action.Name);
        if (elements.Count > 0) {
            if (IsLeaf((XmlElement)elements[0]))
                return elements[0].InnerText;
            else
                throw new Exception("Element '"+action.Name+"' is not a Leaf and cannot be fetched one");
        }
 
        var attribute = element.GetAttributeNode(action.Name);
        if (attribute == null)
            throw new Exception("Element '"+action.Name+"' doesn't exist in xml");
        return attribute.Value;
    }
 
    private bool IsLeaf(XmlElement leafElement)
    {
        return leafElement.ChildNodes.Count == 1 &&
            leafElement.ChildNodes[0].NodeType == XmlNodeType.Text;
    }
}

This class now does all the xml-handling. So that means you can do stuff like this:

1
2
3
4
5
6
7
8
9
10
11
12

string xmlString = 
	"<?xml version=\"1.0\" encoding=\"utf-8\" ?>" +
	"<myXml stat=\"ok\">" +
		"<user id=\"321\" nsid=\"123\">" +
		    "<username>Tore</username>" +
		    "<password>foo</password>" +
		"</user>" +
	"</myXml>";
dynamic myXml = new XmlReader(xmlString);
Console.WriteLine(myXml.stat); // "ok"
Console.WriteLine(myXml.user().username); // "Tore"
Console.WriteLine(myXml.user().nsid); // "123"

This is a real declarative and easy way to handle xml, and since xml will only fail run time anyway, there is no argument that you lose compile time checking either.

I hope that has triggered you a bit on some exciting possibilities on using the dynamic type.

Here’s the source. Please remember you will need C# 4.0 to make this work.

Thanks to this and this blog for giving me information and ideas.

-Tore Vestues

There are a couple of points I want to make here. First I care about writing code that can be easily understood after it is written. Secondly, I want to express as much as possible with as little as possible. I do not want to write five lines of code if I can express the same thing with just one line of code. These two concerns do of course relate. The keywords here are flexibility and efficiency. And let us not forget writing clean, expressive code is a lot more fun than fiddling with repetitive code: How many times have you written code (more than one line) to loop a collection? And how inspiring is it really? We want to loop those collections as easy as possible.

Languages like Python (and its relatives like Ruby and Boo) has put a lot of effort into making working with collections (or lists) as easy as possible. My main language at work nowadays is C#, and I must admit I envy developers in these languages when it comes to collections.

I actually envy them so much that I’ve been reflecting on how we can make our lives easier as well. With .Net 3.5 there is actually something we can do about it.

Collections in Python, Ruby and Boo

But first let me show you what I envy.

Let’s use a simple example to demonstrate my point: We have a list of numbers where we want to make a sub list with all the numbers bigger than 10. In addition, we do of course want to print the sub list to the console.

Boo (one of the most exiting languages for me these days) will simply do it this way:

numbers = [1,15,7,100,3,4,5,19]
print numbers.Collect ({number as int| number>10})

In Boo, lists have built in functionality for making sub lists. I think this code is beautiful. The elegance (and often confusion for C#-developers not familiar with these kinds of languages) is how you declare the conditions for making the sub list. I won’t go into details about this but what we say here is: for the list “numbers”, take each “number” and add it to the sub list if “number>10″. The print statement is all you need to print the list (in an understandable human form) to the console.

It can’t be much simpler than this. Although I actually like the Ruby-way of doing this a micro-tad better:

numbers = [1,15,7,100,3,4,5,19]
puts numbers.find_all{|number| number>10}

I like the find_all method name a bit better than Collect, and I like that you do not have to say “as int”. On the downside the “puts”-statement is a bit less intuitive than plain “print”. But in the long run these are details (or at least we can pretend it is in this context).

In python you can say it like this:

numbers = [1,15,7,100,3,4,5,19]
print [number for number in numbers if number > 10]

Maybe a bit weirder at first glance, but it’s very concise if you’re used to it.

Ok, the point of this was to demonstrate that it is actually quite easy to express a loop very compact and elegant, and this is where I want to be when I loop collections in C#.

Looping collections in C#

The “this will work in almost any language”-code for doing the same job in C# will look something like this:

int[] numbers = new int[] { 1, 15, 7, 100, 3, 4, 5, 19 };
List<int> subset = new List<int>();
 
foreach (int number in numbers)
{
    if (number > 10)
        subset.Add(number);
}
 
foreach (int number in subset)
{
    Console.Write(number + " ");
}
 
Console.WriteLine();

It’s outright horrible compared to the Boo-example! It makes me wonder how many times longer it takes to develop a C#-application, and how much less readable it will be.

So what can we do? Well, let’s see if we can make it simpler.

Using delegates

With .Net 2.0, we were introduced to the concept of delegates (function pointers). It’s an odd concept for the traditional C#/vb/Java-developer. Function pointers are very common in some languages (again, typically in Python and friends), but not in “our” languages. Anyway, I’m really happy that Microsoft introduced us to this as it gives us some interesting possibilities.

We can remove a foreach-loop by using the Array.FindAll-method that takes a delegate. The delegate specifies how to filter the array, and then we have a sub list. This sounds a bit nicer. It looks like this:

int[] numbers = new int[] { 1, 15, 7, 100, 3, 4, 5, 19 };
int[] subset = Array.FindAll<int>(numbers, 
      delegate(int number) { return number > 10; });
 
foreach (int number in subset)
{
    Console.Write(number + " ");
}
Console.WriteLine();

Still a lot of code unfortunately, and the FindAll-method call isn’t really as clear and simple as it could have been either. I won’t go into details about the delegate-concept here, but if you do not understand how it works, I really advice you to take a look. It’s a powerful tool. (Look at my post Delegates, the interface for methods)

Using extension methods

The fact that you can just write “print” in Boo, where I have to write a foreach/Console.Write in C#, annoys me. Let’s fix it.

We could fix this by creating a subclass of Array, and override the ToString()-method. But frankly I do not like the idea. That would mean that everybody everywhere have to use that subclass instead of the standard Array-class. And that isn’t going to happen. There must be an easier way, and it is if you are fortunate enough to be working with .Net 3.0 . Here you can add an Extension Method to the Array-class. Unfortunately you cannot override a method by doing this (i.e. ToString), but you can create new methods on the Array. So let’s do that.

First the extension method:

public static class ArrayExtension
{
    public static void Print(this int[] list)
    {
        foreach (int number in list)
        {
            Console.Write(number + " ");
        }
        Console.WriteLine();
    }
}

And then the main code:

int[] numbers = new int[] { 1, 15, 7, 100, 3, 4, 5, 19 };
int[] subset = Array.FindAll<int>(numbers, 
      delegate(int number) { return number > 10; });
subset.Print(); // extension method

Look at that. I’m feeling better now. We’re getting somewhere.

Using Lambdas

I still do not like the delegate-declaration in the “FindAll”-method call. It’s clumsy, verbose, and not enough to the point. Lambdas introduced in .Net 3.0 will help us simplify this. Read more about lambdas here. For us, a lambda is just an easy way to declare a delegate. Look at this:

int[] numbers = new int[] { 1, 15, 7, 100, 3, 4, 5, 19 };
int[] subset = Array.FindAll<int>(numbers, number => number > 10 );
 
subset.Print();

Sweet! When you get used to it (and you should) the lambda-syntax is very easy to read. And look at how we do not have to declare the types anymore. I really like it. There can be a big difference between how you can do things, and how you should do things. I think this is how you should do it.

Using Linq

Actually, .Net introduces another elegant way to do this, Linq. It has quite a different syntax from most other languages with one notable exception: Sql. Linq treats almost anything like a collection that can be queried. Thus link is in itself a little dsl query language. It’s a great idea, I’ll give Microsoft that. Anyway, this is how our solution will look if we use Linq:

int[] numbers = new int[] { 1, 15, 7, 100, 3, 4, 5, 19 };
var subset =
    from n in numbers
    where n > 10
    select n;
 
subset.Print(); // new extension method

Yes, I like this one too. If you know Sql, and we probably all do, this is very easy to read.

Which one of these two do I like the most? To be honest, I’m not sure. I like them both. Feel free to give your thoughts on the issue.

Conclusion

To be honest I still like the Python/Ruby/Boo- way a little bit better, but with lambdas or linq I think C# is almost as elegant.

I want to make two points here:

First, it’s important to evaluate how we write code. We should always try to find ways to express more with less, and in this case we have been given several tools to help us on the way. It’s just up to us to use them, and use them well.

Secondly, do not let a language limit you. Try different languages and look at how they solve problems in different ways. Many times it will inspire you to find new and better ways to use a language, like here where we’ve applied a little pythonic thinking to C#.

- Tore Vestues