C# in Depth

138 CHAPTER 5 Fast-tracked delegatesC# 2 is a sort of stepping stone in terms of delegates. Its new features pave the wayfor the even more dramatic changes of C# 3, keeping developers reasonably comfortablewhile still providing useful benefits. The extent to which this was a finely balancedact as opposed to intuition and a following wind is likely to stay unknown, butwe can certainly reap the benefits.Delegates play a more prominent part in .NET 2.0 than in earlier versions,although they’re not as common as they are in .NET 3.5. In chapter 3 we saw how theycan be used to convert from a list of one type to a list of another type, and way back inchapter 1 we sorted a list of products using the Comparison delegate instead of theIComparer interface. Although the framework and C# keep a respectful distance fromeach other where possible, I believe that the language and platform drove each otherhere: the inclusion of more delegate-based API calls supported the improved syntaxavailable in C# 2, and vice versa.In this chapter we’ll see how C# 2 makes two small changes that make life easierwhen creating delegate instances from normal methods, and then we’ll look at thebiggest change: anonymous methods, which allow you to specify a delegate instance’saction inline at the point of its creation. The largest section of the chapter is devotedto the most complicated part of anonymous methods, captured variables, which providedelegate instances with a richer environment to play in. We’ll cover the topic insignificant detail due to its importance and complexity.First, though, let’s remind ourselves of the pain points of C# 1’s delegate facilities.5.1 Saying goodbye to awkward delegate syntaxThe syntax for delegates in C# 1 doesn’t sound too bad—the language already has syntacticsugar around Delegate.Combine, Delegate.Remove, and the invocation of delegateinstances. It makes sense to specify the delegate type when creating a delegateinstance—it’s the same syntax used to create instances of other types, after all.This is all true, but for some reason it also sucks. It’s hard to say exactly why the delegatecreation expressions of C# 1 raise hackles, but they do—at least for me. Whenhooking up a bunch of event handlers, it just looks ugly to have to write “newEventHandler” (or whatever is required) all over the place, when the event itself hasspecified which delegate type it will use. Beauty is in the eye of the beholder, of course,and you could argue that there’s less call for guesswork when reading event handler wiringcode in the C# 1 style, but the extra text just gets in the way and distracts from theimportant part of the code: which method you want to handle the event.Life becomes a bit more black and white when you consider covariance and contravarianceas applied to delegates. Suppose you’ve got an event handling methodthat saves the current document, or just logs that it’s been called, or any number ofother actions that may well not need to know details of the event. The event itselfshouldn’t mind that your method is capable of working with only the information providedby the EventHandler signature, even though it is declared to pass in mouseevent details. Unfortunately, in C# 1 you have to have a different method for each differentevent handler signature.Licensed to Rhona Hadida