Last week in the office I thought to my self, “Holiday weekend coming! I’ll have time to play with WP7 or maybe I’ll play with HTML5”. Then I saw this tweet on twitter.

We as developers spend too much time playing with baubles and shiny new tools and not enough time on core skills and fundamentals

I thought well, instead of using some free time this holiday weekend to build something why not do a little research. I happened to have a problem at work which someone suggested using the Visitor Pattern. So I spent some time looking over a few resources and Wikipedia has a great explanation. I won’t try to repeat that. One area I was stuck on though was the concept of double dispatch. I found this example on StackOverflow.com which solidified the concept. For some reason learning by spaceship and rebel alliance works for me.

So now that I had a good understand all I needed to was implement it right? I thought about it and figured that could wait. Now is an opportunity to work on my fundamentals. The Wikipedia article mentioned Common Lisp and how the Visitor Pattern simplified when using dynamic languages. This got me to thinking what would this look like in F# or a functional language?

While looking into functional languages I came across this Stack Overflow question “I am a C# developer, Should I start looking more on F# [closed]”.  Jon Skeet’s answer influenced me and I figured I would pick up a book Real World Functional Programming. It fits into the category of fundamentals because it’s using C# and F# to teach functional programming. Which I haven’t used in many years.

So I start reading with the goal in mind that I would make a quick example of the visitor pattern in F#. Don’t think I am a super geek (not that you would be confused because of my skills). I did take time to drink a few of these and go to the Crowded House concert this weekend. By the fourth chapter or so things started to sink in with F# and functional programming.

If I were using a declarative functional style of programming, I wouldn’t even need the visitor pattern at all!  I don’t have objects that would need to be separated from the algorithm. I would only have types and could use pattern matching and discriminated unions to perform my algorithm. The visitor pattern is needed in my current project because I’m using an implicit OO coding approach.

It was really shocking to me that this wasn’t obvious right away. I’ve been doing OO for so long now I’ve completely become accustomed to dealing with objects and state. A programming world without objects had completely slipped from my mind. Glad I took the time to get started on this book as it’s already giving me new ideas and techniques I can use in my daily C# and OO programming. Now to start working on some of the other programmer competencies.

The latest release of Entity Framework CTP4 has some nice but unexpected changes. They introduced DbContext and DbSet to simplify model caching, database provisioning, schema creation and connection management. Here are my top 5 favorite features of the release.

1. Less code and fewer Concepts. The coolest part is the use of convention over configuration. See the Productivity Improvements walk through and Conventions for code first. I like the extra touch that DbContext  will create the database for you if you want. No code to write. Just use the default CreateDatabaseOnlyIfNotExists.
2. Simplified Database Experience. With the introduction of DbContext and DbSet. EF now takes care of database provisioning, schema creation and connection management. Nice! My favorite part is the Interface IDbConnectionFactory to allow creation of your own conventions.
3. Backwards Compatible. Yes, this is a feature when it comes to CTP’s and Betas. Some projects might just throw stuff away or completely change things on you. EF allows you to still use ObjectContext or Data Annotations for advanced scenarios where common conventions don’t work for you.
4. Simplified Configuration Experience. As I mentioned you can use annotations for this but you also have another cool option. DbContext includes a virtual method that can be overridden to do configuration right in the class. This means no need for separate configuration classes now. I definitely like having it all in one place. Much cleaner and easy to read.
5. Testability IDbSet<TEntity> allows you to define an interface that can be implemented by your derived context. This allows the context to be replaced with an in-memory test double for testing.

I really got a lot out of this code snippet in terms of patterns and syntax. It makes use of some goodies like Delegates, Linq, and IEnumerable. The most interesting part for me though was the recursive call inside the Traverse extension and what it was being used for.

It shows a good pattern for getting values out of nested objects or flatting. Here is a quick sample app using the Traverse extension. Below this I’ve posted some other sources with similar selection patterns.

Link to code with syntax highlighting

class Program
{
static void Main()
{
    var list = new List {new MyClass(10), new MyClass(20)};

    foreach(var l in list)
    {
        l.MyList = new List {new MyClass(10)};
    }
    
    var total = list.Traverse(x => x.MyList).Sum(x => x.Val);

    Console.WriteLine(total);
    Console.ReadLine();
}
}
public static class MyExtensions
{
//The Traverse extension can be added to types of IEnumerable.
//Returns T
//Input Param
//"fnRecurse" - delegate with one parameter T and returns IEnumerable

public static IEnumerable Traverse
       (this IEnumerable source, Func> fnRecurse)
{
    foreach (T item in source)
    {
        yield return item;

        var seqRecurse = fnRecurse(item);

        if (seqRecurse != null)
        {

//Making Recursive call to Traverse using 
//results from the lambda expression 
            foreach (T itemRecurse in Traverse(seqRecurse, fnRecurse))
            {
                yield return itemRecurse;
            }
        }
    }
}
}

public class MyClass
{
public MyClass(int val)
{
    Val = val;
}

public int Val;
public List MyList = new List();
}

Here are some more posts on the same topic:

• a recursive Linq Extentions
• Select Recursive
• Descendants extension