The Visual Basic Team : Jared Parsons

Community Interview with Jared Parsons (Beth Massi)

VBTeam — Wed, 15 Oct 2008 19:00:19 GMT

Here's another community interview from our Italian Visual Basic MVP Alessandro Del Sole, this time with Jared Parsons, a Developer on the VB Team. Jared is a great developer and loves the community. You can check out his personal blog here.

You can also check out the Visual Basic Team page for pictures and bios and visit the home page of the Visual Basic Developer Center for a link to all these interviews as well.

Here's the interview with Jared:

1. Nice to meet you Jared Parsons! Let’s begin by asking a simple question: where are you from?

Born in Kentucky, raised in Tennessee, lived in Alabama for awhile, then back to Tennessee and went to college in Georgia. Usually I simplify it by saying I grew up all over the southeast.

2. We all know that you’re a Visual Basic Team member, but could we know something more about your role inside the Team?

I’m a developer in the VB team. I started out on the VB Compiler several years ago. Towards the end of Visual Studio 2008 I switched to the VB expression evaluator (aka debugger, watch, immediate window). This role expanded to other parts of the VB IDE experience including a lot of features users will be (hopefully) really excited about for the next release of Visual Studio.

3. What’s your favorite Visual Basic feature regarding the language and/or the IDE?

My favorite VB feature is usually whatever I’m implementing at the moment I’m asked this questionJ. Luckily I’m in between features at the moment so I can give an unbiased answer. XML Literals are my favorite VB feature. It really allows me to seamlessly integrate my data and queries into my application. I feel like I find a new way to use it every day.

4. How long have you been working for Microsoft and what was your occupation before joining the VB Team?

I’ve been working at Microsoft for 4 ½ years now. I joined Microsoft immediately after college in the in the Visual Studio Team System division. More specifically I was a developer on Team Developer and Team Architect. After shipping Visual Studio 2005 I was eager for new challenges. I spent a good deal of my time in college working on low level systems and being a teaching assistant for an introduction to compiler courses. I was interested in getting back to these roots. A job opened up on the VB compiler team and it was the perfect fit.

5. Why do you think VB is such a great language?

We have a tie here: flexibility and IDE. VB is an amazingly flexible language. It lends itself to whatever task I’m trying to do. On one end of the spectrum I have XML literals to work with my data and at the other end generics and lambda expressions to really geek out on a problem. The IDE support is also very good (I promise I’m not biased here). It’s really difficult to express everything the IDE offers to the programmer. The best way to understand though is to get out notepad and try and code up a VB application. That will really give you a handle on what the IDE is doing for you.

6. Have you ever been to Italy?

No but it’s definitely on the list of places to visit.

7. Would you like to tell us something about your life outside the office (how do you like to spend your free time, what do you like to do when/if you go out in the evening or when you’re at home and so on)?

Outside of work I still lead a largely geek lifestyle; lots of programming, blogging and book reading. I do manage to leave my geek role by playing a variety of sports. Right now I’m playing soccer (indoor and outdoor), softball and football. I’m not very picky when it comes to sports. As long as it’s athletic and preferably outdoors I’m there. It’s a great way to get release after a day of programming.

Of course there is the occasional Rock Band party as well.

8. Who is your favorite musician?

Much to my parent’s disappointment, I don’t have an ear for music (read that as 100% tone deaf). As a consequence my taste for music is … bad according to my friends. I prefer to think of it as blissful ignorance. On that note (pun intentional) I love a good punk album or some techno while coding.

9. What’s your favorite food?

The hands down winner here is French Fries.

Thank you very much for taking time to answer these questions and letting us know something more about you!

VB Catch ... When: Why so special?

VBTeam — Thu, 09 Oct 2008 18:00:00 GMT

The VB Catch syntax has a unique feature: When. It allows users to filter expressions based on something other than their type. Any arbitrary code can enter a When block to decide whether or not to handle an Exception.

    Sub Sub1()
        Try
            DoSomeAction()
        Catch ex As Exception When Filter(ex)
            Stop
        End Try
    End Sub

Newsgroups often ask, "Why's this so special? I could effectively get the same behavior out of C# by doing the following:"

static void Sub1()
{
    try
    {
        DoSomeAction();
    }
    catch (Exception ex)
    {
        if (Filter(ex))
        {
            throw;
        }
        HandleException();
    }
}

This is true to an extent. In both cases the code is handling an exception and making a decision, via calling Filter, as to whether or not to handle the exception. The subtle difference is when the Filter method is called.

In VB the When statement is actually implemented as an IL exception filter. When an exception is thrown, exception filters are processed before the stack is unwound. This means that if the Filter method created an error report that included the current stack trace, it would show the frame in which the exception occurred.

For example, in the code above if DoSomeAction() threw and the stack was examined in the Filter expression, the following stack would show up.

Notice how the DoSomeAction method is clearly visible? This is incredibly powerful for features like error reporting and investigation. It also allows you to set powerful breakpoints where the exact state of the error can be examined and not just the post mortem.

Alternatively, code executed in the C# block will occur after the stack is unwound. As long as you're not in optimized code you can usually use the stack trace properties to get the source of the exception, but you won't be able to examine the live state of the error.

Channel 9 Interview: Jared Parsons on the P-Invoke Interop Assistant (Beth Massi)

VBTeam — Tue, 29 Jul 2008 04:25:00 GMT

Today I posted an interview screencast on Channel 9. In this interview, Jared Parsons, a Developer on the Visual Basic IDE, shows us the P/Invoke Interop Assistant available on CodePlex. The tool helps with converting unmanaged C code to managed P/Invoke signatures and vice versa. Say goodbye to digging through random header files or MSDN documentation to find the right constants, structures and signatures. The P/Invoke Interop Assistant does a smarter translation for you using SAL (Source Code Annotation Language).

Enjoy,
-Beth Massi, VS Community

PInvoke Interop Assistant on CodePlex (Jared Parsons)

VBTeam — Fri, 20 Jun 2008 19:27:00 GMT

I'm happy to announce that the PInvoke Interop Assistant tool is now available on CodePlex. This includes the binaries, source code and the dev authored unit tests.

It is hosted on the more general CLR Interop Tools page.

http://www.codeplex.com/clrinterop

I will be actively maintaining this tool in the future and (hopefully) adding more features. There were several features we cut just before release due to QA costing that I would like to add back (including VS integration, wrapper functions).

Please post any suggestions you have for the tool on the site and we will definitely consider them.

Jared Parsons

http://blogs.msdn.com/jaredpar

Making PInvoke Easy

VBTeam — Fri, 14 Mar 2008 19:56:17 GMT

Jared here again.

I very excited to announce we recently released a tool I've been working on to MSDN that will greatly help with using PInvoke in managed code. The tool is called the "PInvoke Interop Assistant" and is included as part of a MSDN article on marshalling data for PInvoke and Reverse PInvoke scenarios.

Here is a link to the article and tool

Article: http://msdn2.microsoft.com/en-us/magazine/cc164193.aspx
Tool: CLRInsideOut2008_01.exe

The motivation behind this tool is writing PInvoke is a hard and often tedious task. There are many rules you must obey and many exceptions that must be taken into account. Anything beyond simple data structures gets very involved and subtle semantics of C can greatly change the needed signature. Incorrect translations often result in obscure exceptions or crashes.

In short, it's not any fun.

The tool works in several different ways to make PInvoke generation an easier process. The goal is to make generating managed code for structs, unions, enums, constants, functions, typedefs , etc ... as easy as possible. The resulting code can be generated in both VB and C#.

The GUI version of the tool operates in 3 modes.

SigImp Search: Search for a commonly used function and translate it into managed code.
SigImp Translate Snippet: Directly translate C code into managed PInvoke signatures.
SigExp: Convert managed binaries into C++ Reverse PInvoke scenarios

The first two are the parts I worked on and represent the PInvoke scenarios. The third part was written by Ladi Prosek and will be covered in a different article. We chose the names SigImp and SigExp to mirror the tblimp/tlbexp tool base since they have similar functions.

Directly translating C code into PInvoke Signatures

Most adventures in PInvoke start with a developer having a small set of C code they would like to use from a managed binary. Typically it's one or two functions with several supporting C structs. Before, all of this would be hand translated into managed code from scratch. With this tool all you must do is paste the code into the tool and it will generate the interop signature for you.

For instance assume you wanted to translate the following C code into VB.

struct S1
{
  int a;
  char[10] b;
};

float CalculateData(S1* p);

Start up the tool and switch to the "SigImp Translate Snippet" tab. Then paste the code in and then hit the Generate button.

You can also set click the "Auto Generate" box and watch the code update as you type.

This translation is not limited to built-in C types. It will also resolve most commonly used windows types such as HANDLE, DWORD all the way up to complex structs such as WIN32_FIND_DATA

Searching for a commonly used function

Often developers want to use C functions familiar to them in managed code. This can be a tedious task as well because if the signature is not already available you are back to coding from scratch. Even adding a constant value can be tricky if you don't know which header file to look in.

The tool also provides a database of many commonly used functions, structs, constants, etc ... It is essentially anything that is included from windows.h. Switch to the SigImp search tab, type the name of what you are looking for and hit generate. For example if I want to see the value for WM_PAINT just type it in.

In addition this part of the tool will also do dependency calculation. For instance if choose a method which has a parameter that is a C structure it will automatically generate the structure with the function. For instance if you choose the function FindFirstFile it will determine that the function depends on the WIN32_FIND_DATA structure. Furthermore it will notice that WIN32_FIND_DATA depends on FILETIME and generate both in addition to the method.

<System.Runtime.InteropServices.StructLayoutAttribute( _
    System.Runtime.InteropServices.LayoutKind.Sequential, _
    CharSet:=System.Runtime.InteropServices.CharSet.[Unicode])> _
Public Structure WIN32_FIND_DATAW
    '''DWORD->unsigned int
    Public dwFileAttributes As UInteger
    '''FILETIME->_FILETIME
    Public ftCreationTime As FILETIME
    '''FILETIME->_FILETIME
    Public ftLastAccessTime As FILETIME
    '''FILETIME->_FILETIME
    Public ftLastWriteTime As FILETIME
    '''DWORD->unsigned int
    Public nFileSizeHigh As UInteger
    '''DWORD->unsigned int
    Public nFileSizeLow As UInteger
    '''DWORD->unsigned int
    Public dwReserved0 As UInteger
    '''DWORD->unsigned int
    Public dwReserved1 As UInteger
    '''WCHAR[260]
    <System.Runtime.InteropServices.MarshalAsAttribute( _
        System.Runtime.InteropServices.UnmanagedType.ByValTStr, SizeConst:=260)> _
    Public cFileName As String
    '''WCHAR[14]
    <System.Runtime.InteropServices.MarshalAsAttribute( _
        System.Runtime.InteropServices.UnmanagedType.ByValTStr, SizeConst:=14)> _
    Public cAlternateFileName As String
End Structure

<System.Runtime.InteropServices.StructLayoutAttribute( _
    System.Runtime.InteropServices.LayoutKind.Sequential)> _
Public Structure FILETIME
    '''DWORD->unsigned int
    Public dwLowDateTime As UInteger
    '''DWORD->unsigned int
    Public dwHighDateTime As UInteger
End Structure

Partial Public Class NativeMethods
    '''Return Type: HANDLE->void*
    '''lpFileName: LPCWSTR->WCHAR*
    '''lpFindFileData: LPWIN32_FIND_DATAW->_WIN32_FIND_DATAW*
    <System.Runtime.InteropServices.DllImportAttribute("kernel32.dll", EntryPoint:="FindFirstFileW")> _
    Public Shared Function FindFirstFileW( _
        <System.Runtime.InteropServices.InAttribute(), _
            System.Runtime.InteropServices.MarshalAsAttribute(System.Runtime.InteropServices.UnmanagedType.LPWStr)> _
            ByVal lpFileName As String, _
        <System.Runtime.InteropServices.OutAttribute()> _
        ByRef lpFindFileData As WIN32_FIND_DATAW) As System.IntPtr
    End Function
End Class

Translating Large Code bases

The snippet translator works well for small snippets of code. If you are trying to translate a much larger code base, say several interdependent header files the small snippet dialog won't work well. To work with larger code bases you should use the command line version of the tool; sigimp.exe. It is designed to process several header files and produce a mass output.

Wrapping Up

This tool started out as a pet project of mine some time ago. I'm extremely excited that customers are now going to be able to take advantage of it and I greatly look forward to any feedback you have. I will post a couple more articles in the future detailing how this tool works under the hood.

Jared Parsons

http://blogs.msdn.com/jaredpar

Customizing Displays in the Debugger for System Types

VBTeam — Sat, 29 Sep 2007 02:04:07 GMT

We've heard feedback from several customers regarding the way certain types are displayed in the Debugger. Many of the displays exist to maintain the user experience between versions of Visual Studio. We constantly evaluate if this is the correct choice for a given version of the product.

Starting with VS2008, you don't have to wait for us any longer. In VS2008, VB added full support for many of the debugging features it lacked compared to C# in 2005. In particular we've added full support for the DebuggerDisplayAttribute.

By attributing a class or member with this attribute you can control how it is displayed in the debugger. For each column (name, value and type) you can provide an alternate string or expression to display.

The best part about this attribute is you can target types that exist in different libraries. You don't even need the source for them. One of the members in the Type field which species the target type. Customizing a type in a separate library requires slightly more work than customizing a type you have the source for. For a source project you can just apply the attribute directly to the type or member and it will display. For a type in another library you need to do the following.

Define a class library and include all of the DebuggerDisplayAttribute you want. Make sure to apply the attributes to the assembly and specify the Type member. Ex.

<Assembly: DebuggerDisplay("{ToString}", Target:=GetType(Guid))>

Place the built library under the folder "Visual Studio 2008\Visualizers" which is under your my documents folder.

After doing this any Guid type will now show up as the actual Guid String ("10f3c4eb-7c0f-41b1-ae83-8838ff2f4f70") instead of {System.Guid}

Jared http://blogs.msdn.com/jaredpar/

Closures in VB Part 5: Looping

VBTeam — Thu, 26 Jul 2007 19:42:00 GMT

For previous articles in the series please see

Once again sorry for the long delay between posts.

Looping structures can cause unintended consequences when used with Lambda expressions. The problem occurs because lambda expressions do not execute when they are constructed but rather when they are invoked. For example take the following code.

    Sub LoopExample1()
        Dim list As New List(Of Func(Of Integer))
        For i = 0 To 3
            list.Add(Function() i)
        Next

        For Each cur In list
            Console.Write("{0} ", cur())
        Next
    End Sub

Many users are surprised to find out the above will print "4 4 4 4 ". The reason goes back to my previous 2 posts on variable lifetime and scope. All "For" and "For Each" blocks in Vb have 2 scopes.

Scope where iteration variables are defined
Body of the for loop

The first scope is entered only once no matter how many times the loop is executed. The second is entered once per iteration of the loop. Any iteration variables that are defined in a For/For Each loop are created in the first scope (in this case "i" and "cur"). Hence there is only one of those variables for every loop iteration and the lambda function lifts the single variable "i".

This has thrown off many users because the behavior works most of the time. For instance if I switched the code to run "Console.Write" inside the first loop, it would print out "0 1 2 3 " as expected.

To mitigate against this problem the above code will actually produce a warning in VB.

warning BC42324: Using the iteration variable in a lambda expression may have unexpected results. Instead, create a local variable within the loop and assign it the value of the iteration variable.

There are two ways to fix this problem depending on the behavior you want. If you see this warning and don't know if it affects you, the safest change is to do the following.

    Sub LoopExample2()
        Dim list As New List(Of Func(Of Integer))
        For iTemp = 0 To 3
            Dim i = iTemp
            list.Add(Function() i)
        Next

        For Each cur In list
            Console.Write("{0} ", cur())
        Next
    End Sub

This will cause "i" to be created in the second scope. Hence there will be a different value for every loop iteration and the code will print out "0 1 2 3" as expected.

If you do want the code to print out "4 4 4 4 " then add "Dim i = 0" before the start of the loop.

Jared Parsons(http://blogs.msdn.com/jaredpar)

Closures in VB Part 4: Variable Lifetime

VBTeam — Sat, 16 Jun 2007 00:04:00 GMT

For previous articles in this series please see

Sorry for the long delay between posts here. We're getting Orcas out the door and getting this series completed takes a back seat to shipping.

Originally I wanted to talk about looping structures next. However when I started writing that post I realized that I had to talk about lifetime before the looping structures would make sense.

Prior to Orcas the lifetime of a variable in VB was the entire function. This presented several problems from a closures perspective. Imagine you had a looping structure and the value was used in a lambda expression.

    Sub LifetimeExample()
        Dim list As New List(Of Func(Of Integer))
        For i = 0 To 5

            Dim x = i * 2
            If True Then
                list.Add(Function() x)
            End If
        Next

        For Each f In list
            Console.Write(f() & " ")
        Next
    End Sub

In this example if we left the lifetime rules unchanged, there would be a single variable "x" for the entire function. That means that we would end up printing out

10 10 10 10 10

This is somewhat unexpected and essentially means that VB could not support complex Lambda scenarios. To fix this we altered the lifetime of variables to be tied to the scope they were contained in. The end effect is that each iteration of the loop has a separate "x" since each iteration enters and leaves the scope of the "if" statement. As a result it will print out

0 2 4 6 8 10

We did make one backcompat adjustment for this change. The lifetime of variables in VB was visible if you tried to use an uninitialized variable in a loop/goto. For instance the following code will also print out 0 2 4 6 8 10 because it takes advantage of the fact that the variable "x" has a lifetime longer than the loop.

    Sub VisibleLifetime()
        For i = 0 To 5
            Dim x As Integer
            Console.WriteLine(x)
            x += 2
        Next
    End Sub

To make sure that we didn't break any existing code we had one little errata for the change. When a variable's scope is re-entered, and hence recreated, and it is not initialized to a value it will get the last value of the variable.

Jared Parsons (http://blogs.msdn.com/jaredpar )

Closures in VB Part 3: Scope

VBTeam — Sat, 26 May 2007 00:03:00 GMT

Jared here again. For previous articles in this series please see

Thus far in the series we've only lifted variables that are declared in the same block/scope. What happens if we lift variables in different scope? The answer is that one closure class will be created for every unique scope where a lifted variable is declared and all of the variables in that scope that are lifted will be placed in that closure. Once again, examples speak best

    Sub Scope1()
        Dim x = 5
        Dim f1 = Function(ByVal z As Integer) x + z
        Console.WriteLine(f1(5))
        If x > 2 Then
            Dim y = 6
            Dim g = 7
            Dim f2 = Function(ByVal z As Integer) z + y + g
            Console.WriteLine(f2(4))
        End If
    End Sub

The code will end up looking like so ...

    Class Closure1
        Public x As Integer

        Function Lambda_f1(ByVal z As Integer)
            Return x + z
        End Function

    End Class

    Class Closure2
        Public y As Integer
        Public g As Integer

        Function Lambda_f2(ByVal z As Integer)
            Return y + z + g
        End Function
    End Class

    Sub Scope1()
        Dim c1 As New Closure1()
        c1.x = 5
        Console.WriteLine(c1.Lambda_f1(5))
        If c1.x > 2 Then
            Dim c2 As New Closure2()
            c2.y = 6
            c2.g = 7
            Console.WriteLine(c2.Lambda_f2(4))
        End If
    End Sub

There are a couple of items to take away from this example.

Only two closure classes were created even though three variables were lifted. The number of closures only depends on the number of scopes of all of the lifted declared variables.
The closures are created at the begining of the scope they are associated and not at the begining of the method. This will be more important in the next part of the series.
Each lambda instance is attached to the closure associated with the scope the lambda is declared in.

The next twist is what were to happen if the lambda "f2" were to also use the variable "x". As it's currently written there is no association between Closure1 and Closure2 therefore there is no way for it to access the lifted variable. The answer is two fold. Firstly to reduce clutter I pasted the closure classes as if they were separate entries. In fact Closure2 would appear as a nested class of Closure1 in the real generated code.

Secondly if x were used inside of "f2", the real use would be "c1.x". That's (almost) no different than "someOtherVar.x". Therefore the instance of c1 will be lifted into Closure2.

Dim f2 = Function(ByVal z As Integer) z + y + g + x

Woud result in the following definition of Closure2 ...

    Class Closure2
        Public y As Integer
        Public g As Integer
        Public c1 As Closure1

        Function Lambda_f2(ByVal z As Integer)
            Return y + z + g + c1.x
        End Function
    End Class

In deeply nested lambdas and scopes this type of lifting will continue recursively.

That's it for this entry, the next article will talk about looping structures and possibly variable lifetime.

Closures in VB Part 2: Method Calls

VBTeam — Fri, 04 May 2007 02:22:00 GMT

For previous articles in this series, please see

Part 1 - The basics

Jared here again. This part of the series will focus on how method calls are handled in closures. As stated in the previous article, the purpose of closures is to allow all operations inside a lambda or query expression that would normally be available inside the function or sub. To do this closures often need to capture (or lift) relevant variables from the function into the generated class.

There are 2 types of methods and method calls that closures have to handle.

Method calls to a shared method or methods on modules.
Method calls to instance members of a class

Scenario #1

Below is an example of a method call inside a lambda expression for scenario #1.

Module M1

    Function MyValue() As Integer
        Return 42
    End Function

    Sub Example1()
        Dim x = 5
        Dim f = Function() x + MyValue()
    End Sub

End Module

Here we are calling a module method inside a lambda. Module Methods or Shared methods can be called from anywhere because they require no specific variable for the call. This requires no special work from closures as the call can just be made naturally.

    Class Closure
        Private x As Integer

        Function Lambda_f() As Integer
            Return x + M1.MyValue
        End Function
    End Class

Scenario #2

Calling an instance method is more difficult than a shared method because it requires the referenc "Me". If you don't type this specifically in code the VB Compiler will add it for you under the hood. To make this work the closures code will also "lift" the variable "Me" in the same way that it lifts normal variables in a function.

Calling a instance method inside a lambda expression is little difference than calling a member method on a variable used in a lambda. The only difference is the variable is "Me". For example

Class C1
    Private m_myValue As Integer

    Function MyValue() As Integer
        Return m_myValue
    End Function

    Sub Example2()
        Dim x = 5
        Dim f = Function() x + MyValue()
    End Sub
End Class

In this case we need to access both "x" and "Me.MyValue()" from the closure. The generated code will create space for both of these variables and the transformed code in Example2 will store both of the values.

Class Closure
    Private x As Integer
    Private OriginalMe As C1

    Function Lambda_f()
        Return x + OriginalMe.MyValue()
    End Function
End Class

    Sub Example2()
        Dim c As New Closure
        c.x = 5
        c.OriginalMe = Me
        Dim f = New Func(Of Integer)(AddressOf c.Lambda_f)
    End Sub

As usual, the generated code is much uglier but this essentially what will be generated. That wraps it up for method calls. In the next part, I will discuss the variable liftetime and scoping issues that come into play with closures.

Jared Parsons

http://blogs.msdn.com/jaredpar

Closures in VB: Part 1

VBTeam — Thu, 03 May 2007 06:53:00 GMT

My name is Jared Parsons and I am a developer on the VB Compiler and Debugger. One of the features I implemented for VB 9.0 is lexical closure support. This a great addition to the VB language and I wanted to do a series of blog posts to describe this feature and how it will impact your code.

Lexical Closures (more often referred to as simply Closures) are the underpinnings for several new features in Visual Basic 9.0. The are part of the guts of Lambda and Query expressions. This will be a several part series on Closures in VB 9.0; how they work, their limitations, pitfalls surrounding their use.

To start off, let's get a basic summary of what a Closure is. Wikipedia defines it as "... a is a semantic concept referring to a function paired with an environment ...". I prefer to describe it as follows. A closure is a feature which allows users to seemlessly access an environment (locals, parameters and methods) from more than one function. Even better are samples :)

    Class C1
        Sub Test()
            Dim x = 5
            Dim f = Function(ByVal y As Integer) x + y
            Dim result = f(42)
        End Sub

    End Class

In this code we have a lambda expression which takes in a single parameter and adds it with a local variable. Lambda expressions are implemented as functions in VB (and C#). So now we have two functions, "Test" and "f", which are accessing a single local variable. This is where closures come into play. Closures are responsible for making the single variable "x" available to both functions in a process that is referred to as "lifting the variable".

To do this the compiler will take essentially 4 actions.

Create a class which will contain "x" in order to share it among both functions. Call it "Closure" for now
It will create a new function for the lambda expression in the class "Closure". Call it "f" for now
Create a new instance of the class "Closure" inside the sub "Test"
Rewrite all access of "x" into the member "x" of "Closure".

    Class Closure
        Public x As Integer

        Function f(ByVal y As Integer) As Integer
            Return x + y
        End Function
    End Class

    Class C1
        Sub Test()
            Dim c As New Closure()
            c.x = 5
            Dim f As Func(Of Integer, Integer) = AddressOf c.f
            Dim result = f(42)
        End Sub

    End Class

Now "x" is shared amongst both functions and the user didn't have to know anything about the code we generated. You can see from this simplified example just how much code Closures and all of the other new VB 9.0 features are saving you here (Type Inference, Lambda Expressions).

Note this is only a simulation of what is generated when you use a closure, the actual generated code is much uglier and involves lots of unbindable names "$Lambda_1", etc ...

In the next part of this article I'll dive into some more uses of closures (multiple variables, method access, terminology, etc...).

Jared Parsons

https://blogs.msdn.com/jaredpar