B# .NET Blog

Hi Curious, Steve,

As your questions are very similar, allow me to put the answers in one comment to this post.

The compiler turns out to be pretty smart; when it encounters a scenario with relaxed delegates, it will create a helper function (which is also called a lambda expression, although it doesn't produce a result value necessarily) that does the necessary translation. For example, consider the definition below:

   Delegate Sub Process(ByVal o As Object)

   Sub DoIt(ByRef s As String)

       Console.WriteLine(s)

   End Sub

   Sub Main()

       Dim p As New Process(AddressOf DoIt)

       p(123)

   End Sub

The main function will be compiled as if it were:

   Sub Main()

       Dim p As New Process(AddressOf _Lambda$__1)

       p(123)

   End Sub

   Sub _Lambda$__1(ByRef a0 As Object)

       DoIt(Microsoft.VisualBasic.CompilerServices.Conversions.ToString(a0))

   End Sub

If your DoIt definition would be:

   Sub DoIt(ByRef i As Integer)

       Console.WriteLine(s)

   End Sub

and you were te call it as:

   Sub Main()

       Dim p As New Process(AddressOf DoIt)

       p("123")

   End Sub

the generated "lambda" would be:

   Sub _Lambda$__1(ByRef a0 As Object)

       DoIt(Microsoft.VisualBasic.CompilerServices.Conversions.ToInteger(a0))

   End Sub

Now, if you pass something that's incompatible with the target method, you'll get an InvalidCastException in the cases above and the IDE will mark the p(...) call in Main as the location of the error (because of the hidden generated "lambda" helper).

Indeed, you will only want to use relaxed delegates when it makes sense. There's happening nothing more but runtime object casting. In some repect it's similar to C#'s foreach loop where the loop variable can be declared as a subclass of the collection you're iterating over; in such a case the developer is responsible to know what the collection will contain (the input so to speak):

object[] o = new object[] { 1, 2, 3 };

foreach (int i in o)

  Console.WriteLine(i);

With calling through delegates it's pretty much the same. It just depends on the direction you're taking it. VB 8.0 wouldn't allow the signature of an event handler to be "more general" than the one defined by the object's event you're creating a handler for. Say the method uses a MyCustomEventArgs parameter, but you define a handler that does use EventArgs - nothing is wrong, but it isn't valid for VB 8.0, now it is. Another typical sample is this:

   Sub Main()

       Dim w As New ParameterizedThreadStart(AddressOf Process)

       Dim t As New Thread(w)

       t.Start()

   End Sub

   Sub Process(ByVal w As Worker)

   End Sub

You do know you'll start a thread using a ParameterizedThreadStart and you'll use a Worker object. In here the callee and the caller are tightly coupled, so it makes sense you're able to write this and let the compiler insert the appropriate casts, rather than having to use an Object parameter to the Process method which needs manual casting.

-Bart