Matt Manela's Blog : Visual Basic

Visual Basic .NET Late Binding Explored

MattManela — Sat, 15 Dec 2007 12:14:57 GMT

In a previous post I mentioned how Visual Basic .NET's lambda expressions are more fun and easy to use than C#'s. My inspiration for this statement was the fact that in VB .NET you are able to implicitly define a lambda expression in this way:

Dim f = Function(x) x + x
Console.WriteLine(f(5)) 'Outputs: 10
Console.WriteLine(f("matt")) 'Outputs: mattmatt

When I began looking at this I realized that the type of x was automatically set as Object. That makes sense since its the most basic type but then I wondered how VB is resolving operations like x + x, x * x, and x.length when x is an Object. VB can't know at compile time if those functions exists on the type stored in Object.

Visual Basic deals with these function calls on objects in two different ways.

Mathematical Method call on Object

If the compiler sees that you are doing a recognized mathematical operation it will call the appropriate method from Microsoft.VisualBasic.CompilerServices.Operators. This class defines methods such as AddObject which determines the type of the two object and checks if there is an addition operation defined for them, if so it will execute it. If the types are not compatible or don't have addition defined on them an exception will be thrown. Up to this point all of this work is done by using type checking and type casting. If all of these tests then the objects will be reflected on in an internal function called InvokeUserDefinedOperator. This function will figure out if this the type stored in the object type has the addition operator defined and if all is compatible execute it. The heavy use of reflection is held off until it has to be used since it is much slower. Doing the initial type checking and casting using a large table of known types is a big performance boost for this method since mathematical operates are usually used on standard .NET types.

Any other method call on Objects

In this case the optimization technique used above is not applicable so reflection must be used from the start. To perform this reflection on the objects the Microsoft.VisualBasic.CompilerServices.NewLateBinding class is used. This class defines methods which wrap many of the basic refection methods (it is not meant to be called directly from your code but I am not sure why that is). The method LateGet is called on the objects with the given function and it is attempted to be called. If it doesn't exist an exception is thrown, naturally.

This is just a brief look into how Visual Basic is using late binding to make lambda expressions easier to use.

Lambda Expressions are more fun in Visual Basic .NET

MattManela — Fri, 07 Dec 2007 09:33:35 GMT

I love C# and I would never want to do anything to make it seem any less amazing but I have to give credit where credit is due ... to Visual Basic .NET. Yes, I said it. Both languages have been adding features inspired by the functional and dynamic programing world. However, VB .NET has went a few steps further to truly merge imperative, object oriented, dynamic and functional programing into one convenient package.

Much of this functionality comes from the fact that VB .NET has late binding built in to many of its operations. This allows the programmer to be more expressive and "get away" with more. I was aware that VB .NET had some unique features but as a C# programmer I never got around to playing around with it to see how they feel.

This changed recently when I was fooling around with lambda expressions in C#. I have been casually playing and experimenting with Haskell (a pure functional programing language) for about a year now and I have become very accustomed with just writing a lambda expression and not worrying about defining its type.

With C# 3.0 I assumed I would be able to do the same thing. I wanted to be able to write C# code that is similar to the following Haskell code:

f = \x -> x + x

I figured this would be done easily in C# with the lambda expressions and implicitly typed variables. So I wrote:

var f = x => x + x;

I was very pleased with this code, it looked very close to the Haskell. It is concise, clean and quick however it doesn't compile. You get this error:

Cannot assign lambda expression to an implicitly-typed local variable

The problem is that C# is strongly typed and is unable to determine what type f should be since it cannot determine what type x is. So, you would have to write something like this:

Func<int,int> f = x => x + x;

Now, that isn't hard to do but I don't want to have to write out that type every time I want to create a lambda expression.

I tried the same lambda expression in Visual Basic .NET and ...:

Dim f = Function(x) x + x

Tada!, that worked like a charm. And when I call f(2) it returns 4, and when I call f("matt") it would return "mattmatt".

This was the behavior I was looking for. This peaked my interest in VB .NET and since then I have been exploring features in it and seeing how it performs late binding to make this all happen.

After I experiment some more I will write in detail about what is really going on behind the scenes in the VB .NET Compiler.

Lambda Expressions

MattManela — Wed, 05 Dec 2007 08:55:54 GMT

With the release of C# 3.0 and Visual Basic 9, both languages added support for lambda expressions. Lambda expressions form the basis of lambda calculus which (this will seem a bit mathy) is a formal system which is used to explore mathematical and programmatic topics such as recursion and computability. Lambda calculus plays a crucial role in language theory and formed the foundation for functional programing concepts and type systems.

In MUCH simpler terms a lambda expression is a concise and easy to write anonymous function. Infact C# and VB they are merely syntactic sugar for anonymous delegates. The inspiration for adding them was to simply make passing functions around less cumbersome. For example:

   1: int[] m = new int[] { 0, 5, 10 };   2:     3: Console.WriteLine   4: (   5:     m.Where   6:     (   7:         delegate(int x)    8:         {    9:             return x > 4;   10:         }  11:      ).Average()  12:  );  13: //Outputs: 7.5

This snippet takes an array of integers, filters it to only values greater than 4, and then takes its average. We pass in an anonymous delegate to the Where clause to define how we want to filter the array. While this works great and is readable it is needlessly verbose. With the addition of lambda expression that code becomes:

   1: int[] m = new int[]{0, 5, 10};   2:     3: Console.WriteLine   4: (   5:     m.Where(x => x > 4).Average()   6: );   7: //Outputs: 7.5

Now I can hear everyone screaming "SO WHAT!". And I will admit it isn't a huge change, but it is cleaner and easier to read.