In part one of this series I showed an example of encapsulation within a local definition. This is useful to know so that you are aware of the scope of value holders etc. but what I am more interested in is encapsulation with regards to generating useful F# code libraries in .Net, this is done by using Namespaces and Modules.

Lets have a look at some C# code first…

using System;
namespace EncapsulationNS
{
    public class EncapsulationCLS
    {
        public static void TestMethod()
        {
            Console.WriteLine("Hello");
        }
    }
}

Pretty simple stuff… now the F# equivalent….

namespace EncapsulationNS
module EncapsulationMDL =
    
let TestFunction = 
    System.Console.WriteLine("Hello")
    ()

Even easier… lets look at some specifics about F# namespaces…

• Namespaces are open. meaning you can have multiple source files and assemblies can contribute to the same namespace.

So, Namespaces are a great way to group modules together, so the question needs to be asked, what role do modules play. For me, the F# module is in many ways similar to the vb6 days of modules. In vb6 modules were separate files and simply allowed us to group certain methods together. I find it easier to visualize F# modules this way than to compare them to the C# classes. However that being said one is not restricted to one module per file – there is flexibility to have multiple modules in one code file however with my limited F# experience I would still recommend using the file as the standard level of separating modules as it is very easy to then find your way around a solution.

An important note about interop with F# and other .Net languages. I wrote a blog post a while back about a very basic F# to C# interop.

If I were to reference an F# library in a C# project (for instance ‘TestFunction’), in C# it would show this method as a static method call, meaning I would not have to instantiate an instance of the module.