After writing my last blog entry on Deferred Execution in LINQ I had a conversation with Seth Schroeder who rightly pointed out among other things that I really didn't show how LINQ's deferred execution works internally. So in this post I wanted to implement my own LINQ Where() extension method based off of the one in the System.Linq namespace. So I'll show you the code, explain interesting parts of how it works including collection initializiers and extension methods, and then explain where the deferred execution behavior comes from (i.e. the yield statement). I will only explain in the context of LINQ to Objects since that's far simpler than other Linq's. I will implement a Where() like LINQ to SQL does in a later blog post (that's where things get really crazy).
Implementing MyWhere()
Let's start out with some code. The first question is does this compile?
using System;
using System.Collections.Generic;
using MyExtensionMethods;
namespace PlayingWithLinq {
public
class LinqToObjects
{
public
static void
DoStuff() {
IList<int> ints =
new List<int>() {9,8,7,6,5,4,3,2,1};
IEnumerable<int> result = ints.MyWhere(i
=> i < 5);
foreach (int i
in result) {
Console.WriteLine(i);
}
}
}
}
namespace MyExtensionMethods {
public
static class
ExtensionMethods {
public
static IEnumerable<TSource>
MyWhere<TSource>(
this
IEnumerable<TSource> source,
Func<TSource, bool> predicate
) {
foreach (TSource element in source) {
if (predicate(element)) {
yield return
element;
}
}
}
}
}
Side note: putting two namespaces in on file is far from a best practice, but yes that is allowed.
Lambdas and Collection Initializers
If you're new to C# 3.5 then your first thought may be that:
IList<int> ints = new List<int>() {9,8,7,6,5,4,3,2,1};
is not allowed. Actually it is. It's the collection initializer syntax that I initially whined about in my post C# 3.0: The Sweet and Sour of Syntactic Sugar (ironically I actually like this syntax the more I use it.)
Your next thought may be that:
i => i < 5
is not legitimate. This is in fact a Lambda Expression, and as I explained in Deferred Execution, The Elegance of LINQ it conceptually compiles down to an anonymous method. Incidentally those that know Groovy (myself not included) or Lisp may know this as a closure since as we'll see later it can access local variables.
Extension Methods
Ok, the .Net Framework certainly has no MyWhere() function on the List object so this certainly wouldn't compile in C# 2. But that's where C# 3's Extension Methods come in. The "this" in:
MyWhere<TSource>(this IEnumerable<TSource> source,
says that MyWhere() can be applied to any generic IEnumerable. If you want to, you can still call MyWhere() normally:
IList<int> ints = new
List<int>()
{9,8,7,6,5,4,3,2,1};
ExtensionMethods.MyWhere(ints, i => i < 5);
And in fact this is what the compiler does in the background when you call MyWhere() off of an IEnumerable. But now with extension methods you don't have to.
But does MyWhere() now exist on all IEnumerable objects everywhere? No, it turns out you only get MyWhere() when you import the namespace it exists in (MyExtensionMethods). Incidentally unlike Groovy and Ruby there is no way to add an extension method to a class itself, only to instances.
Whose got the Func()?
The last two questionable parts of the code are the Func<TSource, bool> and the yield. Func is pretty easy. It's simply one of several new predefined delegates (method signatures) that comes with the .Net framework off of the System namespace. The two generic argument one above will match any function that returns the second generic argument and takes the first generic argument as a parameter. It looks like this:
delegate TResult Func<T, TResult>(T arg1);
So rather than using a Lambda expression in my initial example I could have been very explicit about the delegate instance (myFunc):
public
static void
DoStuff() {
IList<int> ints = new
List<int>()
{9,8,7,6,5,4,3,2,1};
Func<int, bool> myFunc
= IsSmall;
IEnumerable<int> result = ints.MyWhere<int>(myFunc);
foreach
(int i in
result) {
Console.WriteLine(i);
}
}
public static
bool IsSmall(int
i) {
return
i < 5;
}
And that would have done the same thing. Notice I had to specify the generic type on the call to MyWhere() since the compiler can't infer the type in this example.
Yield
Now the really interesting part: yield. Yield is what makes deferred execution work. It actually was introduced with C# 2.0, but I don't think anyone really used it (I didn't know about it until recently). So because MyWhere() returns an IEnumerable (and because it isn't anonymous and doesn't have ref or out parameters) it is allowed to use the yield statement. When a method has a yield return (or yield break) statement, then execution of the method doesn't even begin until a calling method first iterates over the resulting IEnumerable. Execution then begins in the method and runs to the first yield statement, returns a result, and passes execution back to the caller. When the calling method iterates to the next value execution continues in the method where it left off until it gets to the next yield statement and then it passes execution back to the caller again and so on. Weird huh? Joshua Flanagan has a nice article that explains this in more detail along with some of the nice benefits like a smaller memory footprint.
So here's a quiz. What happens when you execute the following code?
IList<int> ints = new
List<int>()
{9,8,7,6,5,4,3,2,1};
IEnumerable<int>
result = ints.MyWhere<int>(i => i < 4);
ints.Add(0);
foreach (int i
in result) {
Console.WriteLine(i);
}
Without the yield you'd get the numbers 3 through 1 since you added 0 after the call to MyWhere(). But since the yield in MyWhere() (and the Where() in System.Linq) defers execution until the foreach statement, you actually get 3 through 0. Ready for a little more mind bending? How about this:
IList<int> ints = new
List<int>()
{9,8,7,6,5,4,3,2,1};
int j = 4;
IEnumerable<int>
result = ints.MyWhere<int>(i => i < j);
ints.Add(0);
j = 3;
foreach (int i
in result) {
Console.WriteLine(i);
}
Does the state of j get captured? My intuition would say yes. If so you'd expect 3 through 0. Well, the closure part of anonymous methods and lambdas work by keeping a reference to their calling object (this). So consequently they always get the most up to date value of a variable. So if your intuition works like mine you'd be wrong. You actually get the numbers 2 through 0. Crazy huh? And definitely something I hope I won't run into in someone's code (JetBrains ReSharper actually warns you if you do something crazy like this).
Conclusion
If this made sense then you should have a pretty solid grasp of how most of Linq to Objects works. Understanding extension methods, Func delegates, and yield statements should form the majority of what Linq does. Well, except for expression trees. But that's a topic for another post. Please post if this doesn't make sense or if I got it all wrong, I'd love to hear from you.
Comments