Returning to the foreach construction with Duck Typing for LINQ

I promise that this time there will be a short article (relatively). You all know the foreach language construct in C #, don't you? But think twice before saying exactly how the following code works:

foreach ( int x in src) { // Do something with x. } * This source code was highlighted with Source Code Highlighter .

1. foreach ( int x in src) { // Do something with x. } * This source code was highlighted with Source Code Highlighter .
2. foreach ( int x in src) { // Do something with x. } * This source code was highlighted with Source Code Highlighter .
3. foreach ( int x in src) { // Do something with x. } * This source code was highlighted with Source Code Highlighter .
4. foreach ( int x in src) { // Do something with x. } * This source code was highlighted with Source Code Highlighter .

foreach ( int x in src) { // Do something with x. } * This source code was highlighted with Source Code Highlighter .

Already know the answer? Let me disappoint you: if you have only one answer, then you are mistaken . There is no one answer to the question, because you need to know more about the type of the src variable in order to make a final decision about how the above code works ...

Obviously, you must say that the object must implement IEnumerable or IEnumerable <T>, and maybe you even mention that in the first case, the compiler will type for you when it gets the value "x", causing the IEnumerator.Current property. In other words, you convert the code into something like this:

1. var e = src.GetEnumerator ();
2. while (e.MoveNext ())
3. {
4. var x = ( int ) e.Current; // without the cast if src was an IEnumerable <T>
5. // Do something with x.
6. }

* This source code was highlighted with Source Code Highlighter .

Worthy attempt, but not quite true. First of all, the variable x is declared in the outer zone of visibility (which causes some trouble, if we talk about closures, but now we have a completely different topic ...). Secondly, the enumerator can implement IDisposable, and in this case, the foreach construct provides the correct release of a for “using”:

1. {
2. int x;
4. using ( var e = src.GetEnumerator ())
5. {
6. while (e.MoveNext ())
7. {
8. x = ( int ) e.Current; // without the cast if src was an IEnumerable <T>
9. // Do something with x.
10. }
11. }
12. }

* This source code was highlighted with Source Code Highlighter .

This is more reasonable, but we missed another type of source that foreach can work with: it is any object, as long as it provides the GetEnumerator enumeration template in tandem with MoveNext and Current. For example, here’s an object that works just fine with the foreach construct.

1. class Source
2. {
3. public SourceEnumerator GetEnumerator ()
4. {
5. return new SourceEnumerator ();
6. }
7. }
9. class SourceEnumerator
10. {
11. private Random rand = new Random ();
13. public bool MoveNext ()
14. {
15. return rand.Next (100)! = 0;
16. }
18. public int Current
19. {
20. get
21. {
22. return rand.Next (100);
23. }
24. }
25. }

* This source code was highlighted with Source Code Highlighter .

How it is used is shown below:

1. foreach ( int x in new Source ())
2. Console .WriteLine (x);

* This source code was highlighted with Source Code Highlighter .

Ok, flexible, isn't it? In fact, it can be said that in the foreach construction, duck typing : it is not the nominal type that matters (that is, when Source is explicitly declared as IEnumerable and SourceEnumerator as IEnumerator), but only the structure of the object, which determines “compatibility” with the foreach construction .

But who said that foreach over the collection immediately begins to think about LINQ? Suppose the Source class is used like this:

1. List < int > res = new List < int > ();
2. foreach ( int x in new Source ())
3. if (x% 2 == 0)
4. res.Add (x);

* This source code was highlighted with Source Code Highlighter .

Looks like a great candidate for LINQ, especially if we started adding more and more logic to our “request”. There is nothing surprising in this conclusion, but in reality, unfortunately, it falls and does not compile:


')
Why? Because in LINQ static typing (update: in this place, the author asks to read the comments on his article and agrees that it would be more accurate in this case to speak about LINQ to Objects) , so LINQ expects me to refer to the nominal implementation enumerator: to something that is explicitly defined as an IEnumerable, and not to something that "accidentally" turned out to be similar to an IEnumerable. Question of the day: how to convert an existing structural enumerator into a nominal one so that it can be used with LINQ? Of course, we can write a special code for the Source object, which will create the necessary iterator from Source:

1. static void Main ()
2. {
3. var res = from x in IterateOver ( new Source ())
4. where x% 2 == 0
5. select x;
7. foreach ( var x in res)
8. Console .WriteLine (x);
9. }
11. static IEnumerable < int > IterateOver (Source s)
12. {
13. foreach ( int i in s)
14. yield return i;
15. }

* This source code was highlighted with Source Code Highlighter .

But perhaps you are in such a situation, when there is a whole abundance of such structural enumerators around (for example, some Office automation libraries provide GetEnumerator in types like Range, while the Type type does not implement IEnumerable interface, therefore, it is not suitable for use with LINQ) so you want to summarize the above solution. In essence, we need the ability to add an iterator with duck typing over any object and this is a suitable task for the extender method and the dynamic keyword from C # 4.0:

1. static class DuckEnumerable
2. {
3. public static IEnumerable <T> AsDuckEnumerable <T> ( this object source)
4. {
5. dynamic src = source;
7. var e = src.GetEnumerator ();
8. try
9. {
10. while (e.MoveNext ())
11. yield return e.Current;
12. }
13. finally
14. {
15. var d = e as IDisposable;
16. if (d! = null )
17. {
18. d.Dispose ();
19. }
20. }
21. }
22. }

* This source code was highlighted with Source Code Highlighter .

Question to the reader: why can't we just write a foreach loop over an “object that is cast to dynamic”? Hint: how then do you implement the translation of the foreach construct in a dynamic object?

Yes, you will pile up the required list of methods on System.Object, so be careful with using this, or simply use a call to the old flat method to "translate" the structural into the nominal. Notice how easy it looks like dynamically typed code in C # 4.0. With a large number of type conversions, it looks like this:

1. static class DuckEnumerable
2. {
3. public static IEnumerable <T> AsDuckEnumerable <T> ( this object source)
4. {
5. dynamic src = (dynamic) source;
7. dynamic e = src.GetEnumerator ();
8. try
9. {
10. while (( bool ) e.MoveNext ())
11. yield return (T) e.Current;
12. }
13. finally
14. {
15. var d = e as IDisposable;
16. if (d! = null )
17. {
18. d.Dispose ();
19. }
20. }
21. }
22. }

* This source code was highlighted with Source Code Highlighter .

And now we can write this:

1. var res = from x in new Source (). AsDuckEnumerable < int > ()
2. where x% 2 == 0
3. select x;
5. foreach ( var x in res)
6. Console .WriteLine (x);

* This source code was highlighted with Source Code Highlighter .

Dynamic glue - why not? In fact, even objects from other languages ​​(like Ruby or Python) that follow the paradigm of duck typing now work with LINQ, and for existing compatible objects, calling the operator is harmless (but wasteful). Oh, and note that you can also have an IEnumerable in “dynamic” objects if you are dealing with objects from dynamic languages ​​...

Can you implement the AsDuckEnumerable method in C # 3.0? Of course, if you limit yourself to reflection-based methods (left as an exercise for the reader).

Enjoy!