The C# Makeover

Wednesday, August 29, 2007 - This post was supposed to be all about Lambda Expressions and how you can use these to strip some serious lines of code from your application. As I started working with some examples it became clear to me that Scott Guthrie already said pretty much all that needs to be said about that. What's more interesting to me is what's happening to the C# language feature set! On one hand it looks like things are getting a lot cleaner and more fun (Extensions, the new Property declaration syntactic sugar, etc) but I have to tell ya - I'm starting to get confused a bit these new kids - vars and Lambda expressions, and what they're doing here. You might be thinking "what's so confusing about a var or a Lambda - dude that's CS 101!" and I'd say you're right. Why are they here in my statically-typed C#?

As far as technical things go - It's easy to understand how to use vars and Lambdas, it's harder to understand when or why to use them.

So let's get this out of the way up front: C# is a typed language; always has been, always will be. Microsoft is introducing some new keywords and abilities to C# with the 3.0 version that will allow it to be a little "looser" and more "dynamic" - but it's important to also understand that

vars and Lambdas were introduced to facilitate LINQ. You may now continue with your normally scheduled programming...

Given that - I think it's very important to understand what these things are doing "under the hood" so you can understand when to use them. Vars Are Not Ducks There are some who've compared vars to Ruby's (and other dynamic languages) ability to do type-interpretation on the fly (duck-typing), and that's not the case at all with vars. In fact I'll go so far as to say that it's not even close. Duck Typing (and dynamic-language programming in general) is a different approach and mindset altogether. I'll get to that later - for now I want to go into how vars work. Vars need to know what's coming in order to type themselves. You can't fool Mother Compiler - you can only hold her off for a bit. In this case a var is "late-typed" (or latent-typed) based on what you assign it to:

var myBadHabit = DateTime.Now;

If you compile this statement then look at the IL, you'll see:

.locals init ([0] DateTime myBadHabit)

When using LINQ, a var is "late-typed" for you to be the return set (the "select" statement) so that you can use a typed result set for the query return. So in the following LINQ query, "result" is our Anonymous Type that's typed as ... <AnonymousType>:

Northwind.NorthwindContext db = new NorthwindContext();

var result =

      from products in db.Products

      select new {products.ProductID, products.ProductName};

If I open up reflector, The IL looks like this (it's kind of fun to see LINQ's Expression Tree here and all the code that's saved by the sugary LINQ syntax):

ParameterExpression CS$0$0000;

NorthwindContext db = new NorthwindContext();

var result =

db.Products.Select(

        Expression.Lambda(Expression.New((ConstructorInfo)

        methodof(<>f__AnonymousType0<int, string>..ctor, <>f__AnonymousType0<int, string>),        new Expression[]

        { Expression.Property(CS$0$0000 = Expression.Parameter(typeof(Product), "products"),

        (MethodInfo) methodof(Product.get_ProductID)),

        Expression.Property(CS$0$0000,

        (MethodInfo) methodof(Product.get_ProductName)) },

new MethodInfo[] { (MethodInfo)

        methodof(<>f__AnonymousType0<int, string>.get_ProductID, <>f__AnonymousType0<int, string>),

        (MethodInfo) methodof(<>f__AnonymousType0<int, string>.get_ProductName, <>f__AnonymousType0<int, string>) }),

new ParameterExpression[] { CS$0$0000 }));

Of particular note here is <>f__AnonymousType0<int, string> - this is my return type (since I'm saying select new ProductID and ProductName). Moreover, looking around Reflector a bit I can see that this class is declared as part of my project (as well as a note saying this was compiler-generated). I went ahead and took a look at this Anonymous Type and here's what it decompiles too (note the use of the constructor, as well as the methods hidden from the debugger - wonder why they do that?):

[CompilerGenerated, DebuggerDisplay(@"{ ProductID = {ProductID}, ProductName = {ProductName} }", Type="<Anonymous Type>")]

internal sealed class <>f__AnonymousType0<<ProductID>j__TPar, <ProductName>j__TPar>

{

    // Fields

    [DebuggerBrowsable(DebuggerBrowsableState.Never)]

    private readonly <ProductID>j__TPar <ProductID>i__Field;

    [DebuggerBrowsable(DebuggerBrowsableState.Never)]

    private readonly <ProductName>j__TPar <ProductName>i__Field;    // Methods

    [DebuggerHidden]

    public <>f__AnonymousType0(<ProductID>j__TPar ProductID, <ProductName>j__TPar ProductName)

    {

        this.<ProductID>i__Field = ProductID;

        this.<ProductName>i__Field = ProductName;

    }

[DebuggerHidden]

    public override bool Equals(object value)

    {

        var type = value as <>f__AnonymousType0<<ProductID>j__TPar, <ProductName>j__TPar>;

        return (((type != null) && EqualityComparer<<ProductID>j__TPar>.Default.Equals(this.<ProductID>i__Field, type.<ProductID>i__Field)) && EqualityComparer<<ProductName>j__TPar>.Default.Equals(this.<ProductName>i__Field, type.<ProductName>i__Field));

    }

[DebuggerHidden]

    public override int GetHashCode()

    {

        int num = 0x6d97624d;

        num = (-1521134295 * num) + EqualityComparer<<ProductID>j__TPar>.Default.GetHashCode(this.<ProductID>i__Field);

        return ((-1521134295 * num) + EqualityComparer<<ProductName>j__TPar>.Default.GetHashCode(this.<ProductName>i__Field));

    }

[DebuggerHidden]

    public override string ToString()

    {

        StringBuilder builder = new StringBuilder();

        builder.Append("{ ProductID = ");

        builder.Append(this.<ProductID>i__Field);

        builder.Append(", ProductName = ");

        builder.Append(this.<ProductName>i__Field);

        builder.Append(" }");

        return builder.ToString();

    }

// Properties

    public <ProductID>j__TPar ProductID

    {

        get

        {

            return this.<ProductID>i__Field;

        }

    }

public <ProductName>j__TPar ProductName

    {

        get

        {

            return this.<ProductName>i__Field;

        }

    }

}

The upshot here is that vars generate some serious code - all for good reason when using LINQ: But NOT for a good reason if you're being lazy - which is the point of this whole post.

If you find yourself using "var" anywhere that's not within a LINQ statement, it's probably not a good idea.

It's not duck-typing, and the compiler doesn't "infer" anything - you tell it exactly what you need and it will make it for you (which is kind of groovy). I think it's worth going further here, showing explicitly what duck-typing is and why some people love it. I'll be using Ruby (surprise) for these examples. Ruby, Quack For Me Phil Haack wrote up a nice post about some "duck-typey" feature in C#, and how they can benefit you. While I disagree that these things are anything but "late" or "coerced" typing - I totally agree with the spirit of the article:

The problem for me is [that] this is a lot more code to maintain just to get around the constraints caused by static typing. Is all this additional code worth the headache?

When C# or Java developers talk about dynamic languages, they're usually dismissed as "silly" or "hippy" languages that slow down a processor and bring a non-threaded web server to it's knees. This is all changing as servers get bigger, and popular web servers (like Apache and IIS) implement threaded CGI support. In fact IIS 7 is stating pretty clearly that it will run PHP and Ruby up to 5 times faster than other platforms, simply because of it's native threading/pooling model (using FastCGI). So don't be surprised to find yourself coding in Ruby someday (if you're not already). It takes a while to get used to not having types, but pretty soon you'll get the hang of the language, and in fact come to realize that:

Duck-typing is all about what an object does, not what it is - The Cuato Rule

To some that might read like a license to be sloppy. To a Ruby-head they see Java/C# as a reason to be verbose and "codey". In the spirit of Detente, and getting to know each other, let's take Phil's example of a Duck/Rabbit and put it in terms of code:

Suppose we have a method that takes in a duck instance, and another method that takes in a rabbit instance. In a dynamically typed language that supports duck typing, I can pass in my object to the first method as long as my object supports the methods and properties of duck in use by that method. Likewise, I can pass my object into the second method as long as it supports the methods and properties of rabbit called by the second method. Is my object a duck or is it a rabbit? Like the above image, it

A Ruby-head might point out that methods don't expect types, they expect abilities - which is sort of splitting hairs on semantics. But it's a valid point since that is the mindset of using a language like Ruby - it's all about what an object can do - because by God if it can, it will!

To do this I am going to use a "Mixin" in Ruby - which is sort of like an interface in C#, and sort of like an INCLUDE in C++. Essentially a Mixin is a module that allows objects to share functionality. In Ruby, a Mixin is considered an "Adjective" to the classes "Noun" (it defines an ability, or "flavor" of the class) - so in our case I'm going to create a Mixin called "Chatty" that will define a method called "greet" which will be shared among the classes:

module Chatty
    def greet(other_animal)
        puts "It's "+other_animal.class.name+" season! Not "+self.class.name+" season!"
    end
end

This method is simply looking at the class names of the objects involved, then outputting something to the screen. Easy enough - now I need to create the classes to implement the Mixin:

class Duck
    include Chatty
end

class Rabbit
    include Chatty
end

Not coincidentally, you need the "include" keyword in Ruby if you're going to use a Mixin - now each of these classes implements the "greet" method. You can overwrite this method if you want by simply writing a new one with the same name.

Finally, let's write out the method, remembering that each animal involved has to be able to "greet" the other:

def converse(animal, other_animal)
    if(animal.respond_to?(:greet) && other_animal.respond_to?(:greet))
        puts animal.greet(other_animal)
    else
        puts "I don't speak "+other_animal.class.name+"-ish"
    end
end

Notice in line 2 that I make a check to see if the animal involved can use "greet", and if not I output something appropriate. We don't care what "Type" of animals are involved here - only that they can greet each other. Now if I run this code:

bugs = Rabbit.new
daffy = Duck.new

converse(bugs, daffy)

The response is:

"It's Duck season! Not Rabbit season!"

This is exactly what Phil was talking about in terms of "I can pass in my object to the first method as long as my object supports the methods and properties of duck in use by that method" however I think it's very, very important to look at this in terms of function - not types. No methods expect a type - just the abilities of the type.

Compiler Freedom
Not having a compiler look over your shoulder for type errors can be a little scary. But dynamic language guys will tell you that you "just need to test more". That's a worth while idea since complete testing is always a good idea.

One of the really neat features of Rails is the way they can interpret methods that don't exist. To illustrate, suppose I have a database full of Ducks and Rabbits, and I want to run a query on the Ducks:

ducks=Duck.find(:all)

This will run a query which returns every duck. If I wanted to add some conditions, I could do that as well:

ducks=Duck.find(:all, :conditions => [:name => 'quackers', :age =>10])

And that works OK, but Rails also offers this little gem:

ducks=Duck.find_by_name_and_age('quackers', 10)

This last bit of code implements the "Missing#Method" exception catcher since this method doesn't exist - I made it up! It then parses the statement into SQL syntax! This works nicely since there's no compiler, and moreover - look at how that reads!

There's a price for this kind of thing, of course - I'll "duck" that and leave it up to you and your needs. If you're not running Twitter, something like Rails can be a good thing for you and your team.

Summary
I really dig that the DLR is going to be folded into .NET and we'll be getting access to all kinds of nice dynamic languages. I'll find it very interesting to see how the community reacts to it's presence. So far .NET has been all about static typing and, let's face it, some verbose code structures - it's nice to see this move towards brevity with things like the new property declarations and Lambda expressions.

What do you think of all this?