I\'ve been playing with HttpWebRequest
s lately, and in the tutorials they always do:
IAsyncResult result = request.BeginGetResponse(
new Async
For completeness, this changes between C# 1.2 (with .NET 1.1) and C# 2.0 (with .NET 2.0). So from 2.0 onwards you can indeed omit the new SomeDelegateType(...)
in most scenarios. Oddly, the tooling hasn't changed, so in the IDE if you type someObj.SomeEvent +=
the IDE will suggest (via tab tab) the full version including delegate type.
AsyncCallback is just a delegate in C#, it is declared as
public delegate void AsyncCallback(IAsyncResult ar);
When you pass the method name itself as long as the signature matches the compiler will usually substitute the code for you, its just shortcut.
You can simply check this using Reflector. If you have this for example.
request.BeginGetResponse(TestMethod, null);
static void (IAsyncResult r)
{
//do something
}
The compiled code will actually look like this.
request.BeginGetResponse(new AsyncCallback(Test), null);
It's the same thing, mostly (there are a few overload rules to think about, although not in this simple example). But in previous versions of C#, there wasn't any delegate type inference. So the tutorial was either (a) written before delegate type inference was available, or (b) they wanted to be verbose for explanation purposes.
Here's a summary of a few of the different ways you can take advantage of delegate type inferencing:
// Old-school style.
Chef(new CookingInstructions(MakeThreeCourseMeal));
// Explicitly make an anonymous delegate.
Chef(delegate { MakeThreeCourseMeal });
// Implicitly make an anonymous delegate.
Chef(MakeThreeCourseMeal);
// Lambda.
Chef(() => MakeThreeCourseMeal());
// Lambda with explicit block.
Chef(() => { AssembleIngredients(); MakeThreeCourseMeal(); AnnounceDinnerServed(); });