Edit [2010-03-01] – turns out Reflector can’t handle reversing any iterator blocks. Ouch.
I’m not sure how helpful this post will be for others, but I needed a place to stick screen shots since I can’t attach files to Reflector’s in-app “Send Feedback” dialog nor when creating posts in their forum.
I was decompiling the Google.GData.Client.dll that comes with the (binary-only in the YouTube SDK msi) YouTubeUploader.exe – normally this wouldn’t make much sense, since the source is right here, but ignore that for the purpose of this post, please. 🙂
Feed<T> in that assembly has a nice Entries property of type IEnumerable<T> (starts @ line 202 in current trunk version of the file) implemented as an iterator block (using “yield return”, “yield break”). It certainly has more logic than the average iterator block you’ll find out there, so I’m guessing part of the work the compiler had to do when implementing it confused reflector. Whatever the cause, Reflector doesn’t currently handle correctly reversing it back to the iterator block in the source.
Reflector still shows you the generated code, of course – it just failed in whatever pass it does to identify these bits as the generated pattern and reverse it back.
Here’s the inner class of Feed<T> that’s generated:
And here’s the Entries property:
Most of the heavy lifting is done in the generated inner class’s MoveNext method. (too long and of too little value to put inline 🙂
If the above looks bizarre and/or you’re still curious about how the iterator pattern is implemented by the compiler (as state machines), read more here:
- Jon’s excellent article on iterator blocks
- Eric’s series of posts on iterator blocks
- Raymond’s series of posts on iterator blocks