Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Extension Methods, DSLs, and Fluent Interface

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 =

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.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • I guess they could have done it better

    by Sadek Drobi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I am one of the biggest fans of c# 3.0 features. Yet I guess that there are things that could have been done better. One of them is this "Extension Methods" story.
    First of all thank you for gently pointing out that both the above lines of code compile to the same thing, but who else will? In ruby case, code still belongs to the object, even when we reopen classes, we add methods to that same object. That means we are keeping our modularity. We should be very careful using extension methods.
    I guess C# team chose the easiest solution, which is to implement such a specific feature. And worse to overload the "." to handle two different things! Yes, two completely different things.
    I guess it won’t be less fluent to use the "#" character, or any other that shows the difference.
    Well even better, to allow an open compiler, and to add a macro mechanism for such a syntactic sugar. Because it, as they like to say, all is about syntactic sugar...

  • Wrong .NET 3.5 sytanx

    by Yuan Seth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Extension methods means to methods, not properties. So I think you forgot to put parenthesis around those method calls.

  • Re: Wrong .NET 3.5 sytanx

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yep, you caught me. I have to admit I do so much VB programming I forget that C# requires empty parenthesis sprinkled all over the place.

  • Fuzzy Border

    by Phil Calçado,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Sating the differences (if any) between DSLs and Fluent Interfaces is a very hard thng. I have some points here:

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p