C#

Adventures in F# - F# 101 Part 8 (Mutables and Reference Cells)

Matthew Podwysocki — Tue, 15 Apr 2008 23:08:37 GMT

Time for another adventure in F#, covering some of the basics of functional programming and F# in particular. Today we'll manage to look more at regular .NET integration and .NET programming. With the previous efforts, we've looked more at functional programming and in turn F# specific things, but want to show that you can do anything normally in F# that you can in C#. To me, F# is the perfect all-purpose language because it can do a lot of the things C# can do, but in turn, F# can do things much more elegantly than C# can, such as Pattern Matching.

Where We Are

Before we begin today, let's catch up to where we are today:

Today's topic will be covering imperative and object oriented programming in F#. There is a lot to cover, so let's get started. But there are a few administrative things to get out of the way first.

Learning F# ala Ted Neward?

Ted Neward recently announced on DotNetRocks Episode 332 that he's in the process of creating a class for F# for Pluralsight. That should be interesting to those who are interested in this series, as well as F# in general. Right now the community is rather small, so efforts like this should be rather rewarding I would hope. Ted's a pretty brilliant guy, so I'd imagine only the best. I'm hoping more details come out soon.

Pattern Matching in C#

Part of this series is intended to bring such concepts as Pattern Matching, Currying and other Functional Programming concepts to the C# developer. After all, the more C# language evolves, the more it seems to fall into the Functional Programming category. In previous posts, I showed how to relate currying to C# and it was less elegant than F# to say the least.

But, let's look at Pattern Matching. Bart De Smet has been posting recently on his blog about bringing the beauty of pattern matching to C#. So far it's been a good six posts into it and I urge you to go ahead and take a look at this series.

But when you read the series, it's all about getting into the low level and compiling expression trees to make the same simple beauty that is F#. Sure, it can be done in C#, but nowhere near as elegant. Performance is another issue that comes to mind with these.

Imperative Programming in F#

This section I'll lay out some of the basics of imperative style programming before I get into the full object oriented approach to programming. So, we'll cover just a few topics and then I'll feel comfortable moving onto the real parts of creating classes and such. We'll cover such things as void types and mutability in this section.

The unit Type

One of the first things I forgot to mention when describing F# functions and values in the unit type. Think of this as the void type in C# that you are used to. It's the type that doesn't accept or return a value. First, let's look at the typical C# program with the void type for Hello World.

    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World");
        }
    }

Now, let's go ahead and look at it from the F# perspective.

#light

let main() =

  printfn "Hello World"

main()

As you will see when you hover over our code is that it is a unit type. That in itself isn't all that interesting. But, what we'll run into is problems when functions return a value, but we're not all that interested in them. What happens? Well, F# will complain that your return value isn't compatible with the unit type, which is essentially true. So, how do you get around that? Let's walk through a simple unit test of a Stack written in F# and unit testing with the xUnit.net framework.

#light

#R @"D:\Tools\xunit-build-1252\xunit.dll"

open System

open System.Collections.Generic

open Xunit

type Stack<'t> = class

  val elements : LinkedList<'t>

  new() = { elements = new LinkedList<'t>() }

  member x.IsEmpty

    with get() = x.elements.Count = 0

  member x.Push element =

    x.elements.AddFirst(element:'t)

  member x.Top

    with get() =

      if x.elements.Count = 0 then

        raise (InvalidOperationException("cannot top an empty stack"))

      x.elements.First.Value

  member x.Pop() =

    let top = x.Top

    x.elements.RemoveFirst()

    top

end

[<Fact>]  

let PopEmpty () =

  let stack = new Stack<string>()

  Assert.Throws<InvalidOperationException>(fun () -> stack.Pop() |> ignore )

The real interesting part you should pay attention to is the last line. As you can see, I am using the forward operator to indicate that I really don't care what the function returns, just that I'm interested in that it executes. This is most likely during such functions that have some sort of side effect to them. I could also use the ignore function instead of the forward operator such as this:

[<Fact>]  

let PopEmpty () =

  let stack = new Stack<string>()

  Assert.Throws<InvalidOperationException>(fun () -> ignore(stack.Pop()) )

This is very helpful in these cases where we really don't care about the return value, instead want to mutate the state of our given object, such as removing a value from a collection and so on.

Mutables

As I said in many posts before, by default all "variables" by which I mean values in F# are immutable. This is a standard in functional programming and all in the ML family. You can easily redefine a value by using the let keyword, but not actually mutate its state. But, since F# is a multi-purpose language on the .NET platform, mutable state can be had. To take advantage of this, mark your value as mutable. Then to change the value, just use the <- operator to reassign the value. Below is a simple example of this:

#light

let mutable answer = 42

printfn "Answer is %i" answer

answer <- 8

printfn "Answer is %i" answer

A key difference from the reassignment is that you cannot change the value type. Whereas I can redefine answer by keep using the let keyword, I can only keep my answer in this above example of the int type.

This can also apply to record types as well where you can change the fields. In the last installment, we talked about record types. Well, by default there as well, the fields for the record type are immutable. But, as with before, that can be changed. I of course like to caution people that mutable state takes a lot of the value proposition away from the side effect free programming that you gain with F# by default. But, nevertheless, you can still do it as noted below:

#light

type Person = { FirstName : string; mutable LastName : string; mutable IsMarried : bool }

let friend = { FirstName = "Courtney"; LastName = "Cox"; IsMarried = false }

friend.LastName <- "Cox-Arquette"

friend.IsMarried <- true

What I was able to do was define a Person record and change a couple of fields while using the <- operator and defining the fields as mutable. Yes, I could have used some scientific calculation or something, but this was easy.

Reference Cells

The last thing I want to touch on in this post is reference cells. You can think of these much as pointers in other languages or reference types. These of course can be of any type. The idea behind using these is to make updating fields as easy as possible. As with mutable fields, you cannot change the type once it has been assigned. To use these, you need to remember three basic operators

ref - Allocates a reference cell
:= - Mutates a reference cell
! - Reads the reference cell

Below is a quick example of mutation through reference cells:

#light

let x = ref 2

x := !x + 25

printfn "%i" !x

What the code example above lets me do is define a reference to the number 2. Then I can change that reference by reading the current x value and adding 25. Then I mutate the existing x value with the result.

Conclusion

This is just meant to be a brief overview to some imperative programming constructs that you might see in .NET, Java, C, C++ and so on. F# is a first class language all the way with constructs that support these things as well as your normal functional programming constructs. I hope we get to cover some of this at ALT.NET Open Spaces, Seattle at some point because I'm sure a lot of people will be interested. Until next time...

xUnit.net RC3 Just Released

Matthew Podwysocki — Thu, 10 Apr 2008 22:37:38 GMT

Well, Brad Wilson and Jim Newkirk must really be busy lately. After I talked about the release of xUnit.net RC2, just today, Brad announced the release of RC3. As always, you can find the latest bits here. This fixes a number of bugs and adds CruiseControl.NET and ASP.NET MVC Preview 2 support as well in addition to the Resharper 3.1 and TestDriven.NET support. For more information about it, check out Brad's post here. More or less, they are feature complete for version 1.0 and the only that I think really is needed at this point is a decent GUI runner and that's well acknowledged as something they are working on. Visual Studio integration would be nice as well...

For my other posts in this series, check them out here:

If you were in attendance at last night's RockNUG appearance, all tests for my demos were using xUnit.net, so I am actively using it right now and will be for my CMAP Code Camp appearance this weekend. However, I did not show the GUI runner because, well, it's not there yet, and instead, the console runner works just fine, thank you. So, go ahead and pick up the latest bits and give the team feedback!

One last note regarding Brad, he was recently interviewed by Scott Swigart and Sean Campbell over at How Software Is Built and gives some interesting insights in the open source world inside and outside Microsoft and his contributions to it. Very good interview and well worth the time to read.

Covering NUnit 2.4.7

Matthew Podwysocki — Tue, 01 Apr 2008 21:34:37 GMT

It's interesting that a flurry of releases of testing frameworks have been released lately with Gallio, xUnit.net and of course NUnit. Charlie Poole recently announced on a lot of the discussion boards I belong to recently that NUnit 2.4.7 was recently released. You can read all about what's been added here with the release notes.

What's New and Interesting?

What's interesting about this release? Well, NUnit no longer depends on log4net, thus getting rid of some dependency issues with regards to the applications under test. What's also interesting is that addition of the RowTest extension to allow multiple sets of arguments to be given to a test. This is the first one that's ever been incorporated into the core of NUnit.

Static Tests in NUnit?

As Andy Stopford noted in my blog yesterday regarding xUnit.net, Charlie recently checked in code to allow static methods for static methods to be tests as well as Setup and TearDown to be static as well. Jim Newkirk, the man behind NUnit and co-creator of xUnit.net, favors that approach of allowing statics. To me, I don't care as much with regards to Startup and TearDown with statics as most of my statics for testing F# is side effect free programming. As it should be with functional programming. Anyhow, what I'd like to see in NUnit is the support for something that I can do in xUnit.net:

#light

#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.core.dll"

#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.framework.dll"

open NUnit.Framework

let rec fib n =

  match n with 

  | 0 | 1 ->  0

  | n -> fib(n-2) + fib(n-1)

  | n when n < 0 -> failwith "Cannot be less than zero"

[<TestFixture>]

let FibOfOneShouldReturnZero() =

  let fibResult = fib(1)

  Assert.AreEqual(fibResult, 0)

If I saw something like this, I'd be a happy man. But until then, I can dream...

Conclusion

Go ahead and pick up your copy today of NUnit. It's been the old standby for many of my projects throughout my career and served me quite well. Next time I'll cover Gallio a little bit as I have neglected it, but it's a huge release.

IoC and Unity - Configuration Changes for the Better

Matthew Podwysocki — Thu, 27 Mar 2008 23:52:01 GMT

In my previous post about Unity and IoC containers, I made note of some changes in the latest drop of the Unity Application Block. As Grigori Melnik, the PM of the Unity and Enterprise Library team noted, Unity should be released in its final form on April 7th, so stay tuned. In the mean time, the latest drop of Unity was on March 24th, so go ahead and it pick it up.

Configuration Changes

As I noted from above, the public APIs really haven't changed all that much. Instead, most of the efforts recently have been around performance improvements in the ObjectBuilder base and the configuration of the container itself. I must admit that previous efforts left me a little cold with having to decorate my classes with the DependencyAttribute. Well, you shouldn't have to do that anymore, now that the TypeInjectionElement has been added so that you can map your constructor arguments and so on. Let's walk through a simple example of doing so.

First, let's go through my basic anti-corruption container that I use for Unity and any other container that I use for registration and so on.

namespace UnitySamples
{
    public static class IoC
    {
        private static IDependencyResolver resolver;
 
        public static void Initialize(IDependencyResolver resolver)
        {
            IoC.resolver = resolver;
        }
 
        public static T Resolve<T>()
        {
            return resolver.Resolve<T>();
        }
 
        public static T Resolve<T>(string name)
        {
            return resolver.Resolve<T>(name);
        }
    }
}

Remember this is just a quick spike sample of my anti-corruption container which was taken from Ayende. And then in order to configure my UnityContainer through the implementation of my IDependencyResolver interface. Let's take a brief look at that:

namespace UnitySamples
{
    public interface IDependencyResolver
    {
        T Resolve<T>(string name);
 
        T Resolve<T>();
    }
}

And then the implementation of the interface for Unity would look like:

using System.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
 
namespace UnitySamples
{
    public class UnityDependencyResolver: IDependencyResolver
    {
        private IUnityContainer container;
 
        public UnityDependencyResolver()
        {
            container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.Configure(container);
        }
 
        public T Resolve<T>()
        {
            return container.Resolve<T>();
        }
 
        public T Resolve<T>(string name)
        {
            return container.Resolve<T>(name);
        }
    }
}

Now, if you look at the constructor for the UnityDependencyResolver above, I am using the default container in order to configure my container. But, I have the option of specifying a name for it as well or even just an index. I could just easily change that code to this and it would work if I name my container default. This is a little bit of a change from before when I had to use the GetConfigCommand() method in order to configure the container which was a bit too chatty for my tastes.

            container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers["default"].Configure(container);

So, the idea that I want to do is create an object graph so that I have classes with dependencies that have dependencies. Without doing AOP and some basic interception, we could take the approach of keeping around something like an IContext which would have our cross-cutting concerns in one location such as logging and whatnot in one area so your objects don't sit there with 16 constructor parameters, and instead has a context from which it can pull. This approach has worked for me in the past, so let's just go through that one right now.

First, let's look at the context that has those cross-cutting concerns and the actual implementation:

namespace UnitySamples
{
    public interface IContext
    {
        ILogger Logger { get; }
    }
}

And then the concrete implementation might look something like this:

namespace UnitySamples
{
    public class UnityContext : IContext
    {
        private readonly ILogger logger;
 
        public UnityContext(ILogger logger)
        {
            this.logger = logger;
        }
 
        public ILogger Logger
        {
            get { return logger; }
        }
    }
}

So, what I do here is inject my logger into my context, and probably anything else that might be cross-cutting as well. So, now in one of my classes, then I can accept the IContext in to do what I need it to do. That would look something like this.

namespace UnitySamples
{
    public class Customer
    {
        public string CustomerId { get; set; }
 
        public string FirstName { get; set; }
 
        public string MiddleName { get; set; }
 
        public string LastName { get; set; }
    }
 
    public class CustomerTasks
    {
        private readonly IContext context;
 
        public CustomerTasks(IContext context)
        {
            this.context = context;
        }
 
        public void SaveCustomer(Customer customer)
        {
            // Save customer
            context.Logger.LogEvent("Saving customer", LogLevel.Information);
        }
    }
}

I'm not doing anything special, instead, just showing how this pattern might apply. And then just tying it all together is my console application (sometimes my favorite UI for quick spikes).

namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IoC.Initialize(new UnityDependencyResolver());
            CustomerTasks tasks = IoC.Resolve<CustomerTasks>();
            tasks.SaveCustomer(new Customer{ CustomerId = "12345", FirstName = "Joe", LastName = "Smith", MiddleName = "Frank"});
        }
    }
}

But the more interesting part about this is the XML configuration. I know many people such as Ayende have declared war on XML configuration, but I think for this quick example it does quite well. If we start talking about complex object graphs, then I'd certainly agree and I'd rather do it programmatically. But, let's first look at how I'd wire up the whole thing in the app.config file.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
    </configSections>
 
    <unity>
        <typeAliases>
            <typeAlias alias="string" type="System.String, mscorlib" />
            <typeAlias alias="ILogger" type="UnitySamples.ILogger, UnitySamples" />
            <typeAlias alias="ConsoleLogger" type="UnitySamples.ConsoleLogger, UnitySamples" />
            <typeAlias alias="DebugLogger" type="UnitySamples.DebugLogger, UnitySamples" />
            <typeAlias alias="IContext" type="UnitySamples.IContext, UnitySamples" />
            <typeAlias alias="UnityContext" type="UnitySamples.UnityContext, UnitySamples" />
            <typeAlias alias="CustomerTasks" type="UnitySamples.CustomerTasks, UnitySamples" />
        </typeAliases>
        <containers>
            <container>
                <types>
                    <type type="ILogger" mapTo="ConsoleLogger" name="defaultLogger"/>
                    <type type="ILogger" mapTo="DebugLogger" name="debugLogger"/>
                    <type type="IContext" mapTo="UnityContext">
                        <typeConfig extensionType="Microsoft.Practices.Unity.Configuration.TypeInjectionElement, Microsoft.Practices.Unity.Configuration">
                            <constructor>
                                <param name="logger" parameterType="ILogger">
                                    <dependency name="debugLogger"/>
                                </param>
                            </constructor>
                        </typeConfig>
                    </type>
                    <type type="CustomerTasks">
                        <typeConfig extensionType="Microsoft.Practices.Unity.Configuration.TypeInjectionElement, Microsoft.Practices.Unity.Configuration">
                            <constructor>
                                <param name="context" parameterType="IContext">
                                    <dependency/>
                                </param>
                            </constructor>
                        </typeConfig>
                    </type>
                </types>
            </container>
        </containers>
    </unity>
</configuration>

As you may notice from above, Unity gives us the ability to give type aliases so that we can reference the short names instead of the long ugly fully qualified type names by using the <typeAliases><typeAlias> nodes in the configuration. Much as before, we still register our types with a name, type and so on.

But, what's interesting is that we now have the ability to do type injection through a Unity extension called the TypeInjectionElement. This allows us to inject into the constructor and put in our parameters as need be. But we could also replace that with <method> or <property> in order to do method injection and property setter injection respectively.
Within the <param> element, we can specify our given injection element parameters. This allows us to specify the name of our given parameter, the type, but also for the dependency check, we can specify the name and type to alias the other <type> elements that we wish to get a reference of. We can also specify the values if we so desire of strings, integers and so on. Below is a simple example of using both dependency references and values.

<constructor>
    <param name="logger" parameterType="ILogger">
        <dependency name="debugLogger"/>
    </param>
    <param name="dbName" parameterType="string">
        <value value="AdventureWorks" />
    </param>
</constructor>

I find the best way to learn about these features usually isn't through documentation, although it's a nice thing to do, but instead the tests. I look for the functionality that I'm interested in and go deep. A project this size without good unit tests == FAIL in my opinion. Anyhow, this is better looking than it used to be and much more intuitive.

Interception Revisited

As Chris Tavares, the developer of Unity noted on my blog before was the fact that he could easily put in the interceptors from the ObjectBuilder2 since ObjectBuilder2 is modular and Unity is built upon it. It shouldn't have been news, because I've been working on that myself to get lightweight interception to work on it. Maybe when I get it fully implemented I'll share it. But in the mean time, it's just a spike.

Conclusion

I think this approach has helped in the XML configuration goo that had been a bit confusing. I didn't want to clutter my domain models and processing code with excess attributes stating intent, and would rather keep it clean. This makes a step in that direction. In the next installation of looking at IoC will revolve around Spring.NET and AOP in the Enterprise, so stay tuned... Until next time...