Extension Methods, DSLs, and Fluent Interface

What is the difference between an Internal DSL and an API? Martin Fowler described an internal DSL back in February of 2004 as,

The lisp and smalltalk communities also have a strong tradition of DSLs, but they tend to do it another way. Rather than define a new language, they morph the general purpose language into the DSL. (Paul Graham describes this well in Programming Bottom-Up.) This Internal DSL (also referred to as an embedded DSL) uses the constructs of the programming language itself to define to DSL. This is a common way to work in any language, I've always thought of defining functions in such a way to provide a form of DSL for my problem. But lispers and smalltalkers often take this much further. Another term for an API written in this style is FluentInterface.

Two and a half years later he says,

For internal DSLs, the fuzzy boundary is what is an API and what is a DSL. Fundamentally there is no difference, an internal DSL is just an API with a fancy name (as the old Bell labs saying goes: "library design is language design"). Despite this, however, I think there is a different feel when you are working with an API that's written with a DSL feel. Things like a FluentInterface can make working with an API a qualitatively different experience. Thinking in DSL terms makes you think about readability in a different way, exploiting the syntax of the host language to create something that seems to stand on its own - rake is a great example of this.

So what exactly does an Internal DSL look like? Usually the answer comes back as an example of fluent programming. In fluent programming, all methods return either the same object or a new object. This allows method calls to be chained together.

For an example, we turn to an excerpt from Neal Ford's QCon presentation "Building DSL's in Static and Dynamic Languages".

def c = 2.days.fromToday.at(4.pm)

Until recently hacking interstice classes like integer required a dynamic language like Ruby or Python, specifically because they provide something called "open classes". An open class allows one to add new methods to a class at runtime.

So what does this have to do with a .NET developer using C# or VB? Well, C# 3 and VB 9 both support something called Extension Methods. Extension methods allow users to statically add methods to a pre-existing class. You could for example create a "days" method that takes an integer and returns a TimeSpan.

Consider the difference between this C# 2.0 code and the same thing written in C# 3.0.

//C# 2.0
date d = Helper.At(Helper.FromToday(Helper.Days(2)), Helper.Pm(4));
//C# 3.0
date d = 2.Days().FromToday().At(4.Pm);

It should be noted that these two lines of code compile to exactly the same thing. All the heavy lifting was done by the compiler and the Extension attribute.

A final tip for using extension methods. Though officially supported only in .NET 3.5, Jared Parsons found a way to use extension methods in .NET 2.0. Basically it comes down to creating a fake "ExtensionAttribute" class that the new compilers confuse for the real one.