I thought of naming this post “Evolution of lambdas in C#”, then I decided that wouldn’t be closest appropriate name for the example that I wanted to discuss. The key to understand a lambda in C# is to understand a delegate. Besides the overly blatant blather – “delegates are nothing but function pointers”, I am going to assert that delegates in C# are very similar to function pointers in C or C++ ;). What did I say? OK!
Let’s get one thing straight, think about the paradigm of passing arguments to a method. A method with a parameter named int i, would allow you to pass any argument like 1, 2, 3, 4, 5, 6, 7, 8, …32767…2147483647.
method(int i)
{
return;
}
So we sort of seem to get a flexibility there (basis of why we wanted a method in programming – reuse, and possibly call it with different arguments), instead of a method that takes a fixed argument, we have a flexibility to pass in a whole range of values. int is a data type. i is the parameter name, those numbers above are arguments. Very easy concept that any programmer under the sun wouldn’t even dare to defy. In case he did, we would all think he’s crazy, or he lost his brains somewhere towards obsession of trying to defy otherwise. Hey, easy, no arguments about the arguments there!
So somehow, we started writing methods to do repetitive actions. And then “fathers of computer programming” thought of passing a method itself as a argument to a method (a method with a parameter, that accepted a certain type of function – just like the way the data type int allowed us to pass 1, 2, 3, 4,….). But we had to do something extra to pass a function as an argument (we will have to define what our delegate is). int had a whole range of values defined – those numbers above. so we did not really have to re-define what an a int really was. For all we know is int is a datatype defined by the language that accepts certain values as arguments.
Well, in case of delegates, we are free to choose the arguments (or the possible set of values that a delegate type can accept). For instance, lets define a delegate in pseudo-code
public delegate int DoSomeMath(int a, int b);
so we defined a delegate!
delegate is a type, just as how int a is a type. We already know that int accepts the numbers above and it constrains itself to the boundaries of those numbers i.e, from 0 to 2147483647, considering signed integer, because the language/compiler writers programmed it that way. Now, the delegate DoSomeMath is capable of accepting any method that takes two int as input and returns an int as output; it constrains itself to any method that takes two int as input and returns an int as output.
What this means is, we can have methods like below, and they all qualify to be the accepted by the delegate type named DoSomeMath .
public int Add(int i, int j) { return i + j; }
public int Sub(int i, int j) { return i - j; }
public int Mul(int i, int j) { return i * j; }
public int Div(int i, int j) { return i / j; }
….
….
….
To summarize, delegate is a type, DoSomeMath is the name of the delegate, all the Add, Sub, Mul, Div methods would qualify to be the arguments of a parameter named math below
InvokeDelegate(DoSomeMath math)
{
math.Invoke(10, 20);
}
Now, that we know how to declare a delegate, and pass a method to it, what’s the point if don’t invoke the method that was passed as an argument? Now, stay with me as I will show you an example of how you could invoke a delegate. Well, you know enough is enough, I tried by best to get a grip on delegates, and that’s how I understood it.
Remember the steps involved,
-
Create a delegate type
-
Create methods matching the delegate
-
Finally, invoke the delegate
What I have seem to have grasped, is that the step 2, was some sort of overhead for developers and Microsoft in it’s C# compiler added anonymous delegates, and later lambda expressions to save some development time by introducing a new syntax – in the industrial parlance, syntax sugar as they call it.
C# delegate syntax
Let’s dive in to C#, and try creating a delegate that seems to incorporate a common real time need. I want to write a little method named PrintAllFiles and make it accept a directory location, and a filter condition. The parameter named condition is special here, because it is delegate type. Lets create that.
private delegate bool FileFilterDelegate(FileInfo file);
The FileFilterDelegate is capable of accepting any method that accepts a FileInfo object and returns a bool. So the two methods below qualify to be our arguments since they both accept a FileInfo parameter and return a bool.
private static bool SmallFileFilter(FileInfo fi)
{
return fi.Length < 100;
}
private static bool LargeFileFilter(FileInfo fi)
{
return fi.Length > 1000000;
}
Now, lets write the PrintAllFiles method
private static void PrintAllFiles(string path, FileFilterDelegate condition)
{
FileInfo[] files = new DirectoryInfo(path).GetFiles();
foreach (var item in files)
{
if (condition(item))
{
Console.WriteLine("File: {0} Size: {1}", item.FullName, item.Length);
}
}
DisplayMethodFooter();
}
Alright, where am I calling the delegate? it is right inside the if condition. item is of the type FileInfo, then I call the method that is passed as an argument (it could be SmallFileFilter, or LargeFileFilter) with an argument named item.
I guess, the benefit of programming with delegates this way is pretty clear. I have the flexibility of defining as many methods as I want, but my PrintAllFiles does not change. I could write another filter tomorrow, as long as it returns a bool and accepts an FileInfo object, I would be able to pass it to my PrintAllFiles method.
Now, we created a delegate, we wrote methods with names SmallFileFilter and LargeFileFilter, and then we invoked it. Couple of options here:
-
condition(item) would Invoke the method passed as an argument
-
condition.Invoke(item) would Invoke the method passed as an argument, just as the previous one did
-
condition.BeginInvoke(item) would Invoke the method passed as an argument in an asynchronous manner.
The essence here is the PrintAllFiles method that accepts a FileFilterDelegate. We could call it like below, by passing it the methods that match the FileFilterDelegate definition.
DisplayHeader("//traditional way - create a method accepting and returning the same types as the delegate");
PrintAllFiles(@"C:", SmallFileFilter);
PrintAllFiles(@"C:", LargeFileFilter);
Using Anonymous Delegates
We created methods named SmallFileFilter and LargeFileFilter, for a reason being that’s how we were accustomed to write a method. Think of some cool names and name the method that way, so I could use that name and call it over and over, or pass it as a delegate argument over and over.
But instead, it I wanted a filter for one-off usage, I really don’t want to create a method and give it a name. I could simply write a method on the fly without a name. how’d I do that? Well, we are talking about Anonymous delegates already.
See the code below, it is just a method right there, without a name. All that is missing there is private static bool SmallFileFilter, private static bool LargeFileFilter; that are essentially replaced by the keyword delegate.
DisplayHeader("//using Anonymous delegates - methods with no name");
PrintAllFiles(@"C:", delegate(FileInfo fi) { return fi.Length < 100; });
PrintAllFiles(@"C:", delegate(FileInfo fi) { return fi.Length > 1000000; });
Now I don’t really need a method with a name. I could just write a method without a name on the fly and that would be considered an anonymous delegate if we prefixed it with the delegate keyword. Point to understand is we didn’t really eliminate the need to write methods, we just eliminated the need to name them.
Lets do some lambdas
We know how to write a method without a name, a method that was supposed to be passed as an argument. We did that by using the delegate keyword. Now as they wanted to make things simple and simple everyday, they made us put a lambda ( => ) instead of the delegate keyword.
DisplayHeader("//using lambda - the delegate keyword is not needed anymore");
PrintAllFiles(@"C:", (FileInfo fi) => { return fi.Length < 100; });
PrintAllFiles(@"C:", (FileInfo fi) => { return fi.Length > 1000000; });
That’s it! We saw how to create a delegate, how to write a method matching the delegate, how to pass it as an argument, how to invoke it.
..and there was this need to not name a method.. we preferred Anonymous Delegates
….then saw how to oust anonymous delegate with a lambda expression.
I guess I have stayed and not swayed from the title of the post. Although, these are not the only uses of lambda, this is one way, you can get a grip on if your lambda highway is slippery yet. Other great articles about lambda expressions, and it’s uses are below. If they are in too detail, a glance would do, that’s what I did.
http://stackoverflow.com/questions/167343/c-sharp-lambda-expression-why-should-i-use-this
http://www.codeproject.com/Articles/17575/Lambda-Expressions-and-Expression-Trees-An-Introdu
http://www.codeproject.com/Articles/24255/Exploring-Lambda-Expression-in-C
http://msdn.microsoft.com/en-us/magazine/cc163362.aspx
Complete source code to test the samples and play with it.
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO; namespace EvolutionOfLamdaExpression2 { class Program { static void Main(string[] args) { DisplayHeader("//traditional way - create a method accepting and returning the same types as the delegate"); PrintAllFiles(@"C:", SmallFileFilter); PrintAllFiles(@"C:", LargeFileFilter); DisplayHeader("//using Anonymous delegates - methods with no name"); PrintAllFiles(@"C:", delegate(FileInfo fi) { return fi.Length < 100; }); PrintAllFiles(@"C:", delegate(FileInfo fi) { return fi.Length > 1000000; }); DisplayHeader("//using lambda - the delegate keyword is not needed anymore"); PrintAllFiles(@"C:", (FileInfo fi) => { return fi.Length < 100; }); PrintAllFiles(@"C:", (FileInfo fi) => { return fi.Length > 1000000; }); DisplayHeader("//using Func delegate - use the inbuilt templatized delegates"); PrintAllFiles2(@"C:", (FileInfo fi) => { return fi.Length < 100; }); PrintAllFiles2(@"C:", (FileInfo fi) => { return fi.Length > 1000000; }); } private delegate bool FileFilterDelegate(FileInfo file); private static bool SmallFileFilter(FileInfo fi) { return fi.Length < 100; } private static bool LargeFileFilter(FileInfo fi) { return fi.Length > 1000000; } private static void PrintAllFiles(string path) { foreach (var item in new DirectoryInfo(path).GetFiles()) { Console.WriteLine("File: {0} Size: {1}", item.FullName, item.Length); } DisplayMethodFooter(); } private static void PrintAllFiles(string path, FileFilterDelegate condition) { FileInfo[] files = new DirectoryInfo(path).GetFiles(); foreach (var item in files) { if (condition(item)) { Console.WriteLine("File: {0} Size: {1}", item.FullName, item.Length); } } DisplayMethodFooter(); } private static void PrintAllFiles2(string path, Func<FileInfo, bool> condition) { FileInfo[] files = new DirectoryInfo(path).GetFiles(); foreach (var item in files) { if (condition(item)) { Console.WriteLine("File: {0} Size: {1}", item.FullName, item.Length); } } DisplayMethodFooter(); } private static void DisplayHeader(string p) { Console.WriteLine("------------------------------------------------------------------------------------------"); Console.WriteLine(p); Console.WriteLine("------------------------------------------------------------------------------------------"); } private static void DisplayMethodFooter() { Console.WriteLine("EOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOMEOM"); } } }