The Visual Basic Team : Scott Wisniewski

Drawing Maps with Visual Basic (Scott Wisniewski)

VBTeam — Mon, 26 Nov 2007 22:35:00 GMT

If you find yourself looking for something to do with your awesome new copy of Visual Studio 2008, you should check out the December 2007 edition of MSDN magazine. It features an article, written by me, that provides a walk through on how to visualize data on a map using VB 9, WPF and LINQ.

To give you a sneak preview of what the app described in the article does, I've included a screen shot below:

Over my next several posts I plan on expanding on the article by showing how you can extend the application by adding new functionality to it. For now, I will give you some time to read through the article, download the code sample, and play around with the app. In my next post I will show how you can make the application multithreaded while still taking full advantage of WPF data binding.

Enjoy!

A Note about Enums (Scott Wisniewski)

VBTeam — Tue, 16 Oct 2007 00:32:00 GMT

I recently received an email from a customer who had a few questions about "enum inheritance" in VB, specifically as to why it wasn't supported. In particular, he sent us the following snippet of VB code (I've changed the names of the classes and methods involved) :

Option Strict On

Public Class BaseClass

    Public Enum SomeEnum
        Value1
        Value2
    End Enum

    Public Overridable Sub DoSomething(ByVal e As SomeEnum)
        Select Case e
            Case SomeEnum.Value1
                DoSomething1()
            Case SomeEnum.Value2
                DoSomething2()
        End Select
    End Sub

    Private Sub DoSomething1()
    End Sub

    Private Sub DoSomething2()
    End Sub

End Class

Public Class DerivedClass
    Inherits BaseClass

    Public Shadows Enum SomeEnum
        Value1
        Value2
        Value3
    End Enum

    Public Shadows Sub DoSomething(ByVal e As SomeEnum)
        Select Case e
            Case SomeEnum.Value1, SomeEnum.Value2
                MyBase.DoSomething(CType(e, BaseClass.SomeEnum))
            Case SomeEnum.Value3
                DoSomething3()
        End Select
    End Sub

Private Sub DoSomething3()
End Sub

End Class

and asked us the following questions:

Why does SomeEnum have to be marked as shadows inside DerivedClass? Why can't I use "overloads"?
Why does DerivedClass.DoSomething() have to cast it's enum value to the value in the base class.

I figured other people may have run into similar issues any may have some of the same questions, and so though this would make a good blog post.

My response is below:

VB does not support "Enum" inheritance, and so it is not possible for one Enum type to inherit from another "Enum" type.

This is mainly because "Enum" inheritance is not safe. In general, an inheritance relationship between two types implies that it is possible to always treat a "more specific" derived class as if it was also a "more general" base class. This relationship does not hold between two enums.

This is because, enum's are really not object-oriented concepts. Instead, an enum is just a collection of constant variable declarations conveniently packaged into a type. What defines the "identity" of an enum is the set of values it may take.

In general, if you were to take an enum like so:

Enum Foo 
    Value1 
    Value2
End Enum

and then try to extend it with inheritance like so (this is not legal):

Enum FooDerived Inherits Foo 
    Value3
End Enum

It would no longer be possible to say that "any FooDerived" is also a "Foo". This is because the value "Value3" cannot be treated as if it was a "Foo" value.

The compiler does, for convenience, provide conversions between different enum types. This is because in the event that you know the value your are converting can be represented in the target type then it is safe to do the conversion. Because it is not always safe, however, the conversion is treated as a "narrowing" (unsafe) conversion rather than a "widening" (safe) conversion.

When "option strict" is turned on the compiler will not implicitly perform unsafe conversions. Instead it requires you to explicitly tell it when a potentially unsafe conversion is in fact safe by writing an explicit "CType".

Marking the SomeEnum type DerivedClass as shadows makes it a completely new enum type from the one defined in "BaseClass". Because "BaseClass.SomeEnum" and "DerivedClass.SomeEnum" are different enum types, the conversion is not safe, and thus requires an explicit cast.

Channel9 Interview: Scott Wisniewski on Extension Methods in Visual Basic 9.0 (Beth Massi)

VBTeam — Fri, 03 Aug 2007 19:46:00 GMT

I just posted an interview with Scott on Channel9 where he talks about extension methods, a new language feature in Visual Basic 9.0:

In this in interview Scott Wisniewski, a Developer on the Visual Basic Team, talks about Extension Methods and shows us a couple interesting LINQ providers. In his own unique way, Scott dives into the meaning of Extension Methods and how they can extend types with discoverable methods which are part of the underpinnings of LINQ. He walks through some code written as an extension to LINQ query results to generate pie charts and then dives into a LINQ provider he built that hooks into Performance Monitor to give you real-time statistics on your LINQ queries. You can also read Scott's MSDN Magazine article here.

Enjoy!

-Beth Massi, VS Community

Lambdas, and Take While, and Group By, Oh My!

VBTeam — Thu, 26 Jul 2007 20:02:00 GMT

Hooray! Visual Basic 2008 Beta2 has been released to the wild today to return to its natural habitat – the desktops of our beloved customers. (Please note our smiling GPM's face on that landing page -- he's so happy the Beta is done.)

What’s inside? So much that there might be more new features than we released in Beta1, but who’s counting? Here’s a laundry list that’s specific to the VB language that’s new for Beta2:

· Query operators

o Group By, Group Join, Join, Take [While], Skip [While], Aggregate, Count, Sum, Min, Max, Average, From à Let

· Nullable support

· Lambda Expressions (aka Inline Functions)

· Partial Methods – ScottGu mentioned this the other day & ScottWis posted a couple weeks back

· Anonymous Types w/Keys – Which PaulV has already discussed

Here are a bunch of queries you can now write with VB!

' Find suppliers in the same city as customers

From cust In db.Customers _

Join sup In db.Suppliers _

On cust.City Equals sup.City _

Select cust.CompanyName, sup.ContactName, cust.City

' Find suppliers in the same city, with the same postalcode as customers

From cust In db.Customers _

Join sup In db.Suppliers _

On cust.City Equals sup.City And cust.PostalCode Equals sup.PostalCode

Select cust.CompanyName, sup.ContactName, cust.City

' Find the average unit price and count for products by category

From prod In db.Products _

Group By prod.CategoryID _

Into Average(prod.UnitPrice), Count()

' For each customer find the group of the suppliers in the same country

From cust In db.Customers _

Group Join sup In db.Suppliers _

On cust.Country Equals sup.Country _

Into SuppliersInCountry = Group _

Select cust.CompanyName, SuppliersInCountry

' For each customer, the count of the number of suppliers in the same country

From cust In db.Customers _

Group Join sup In db.Suppliers _

On cust.Country Equals sup.Country _

Into NumSuppliers = Count() _

Select cust.CompanyName, NumSuppliers

' Avg price, avg # in stock, and max on order for non-discontinued products

Aggregate prod In db.Products _

Where Not prod.Discontinued _

Into AvgPrice = Average(prod.UnitPrice), _

AvgInStock = Average(prod.UnitsInStock), _

MaxOnOrder = Max(prod.UnitsOnOrder)

' Find orderID, OrderDate, and OrderTotal for each order

From order In db.Orders _

Where order.OrderDate > #7/22/1996# _

Aggregate ordDet In order.Order_Details _

Into OrderTotal = _

Sum(ordDet.UnitPrice *ordDet.Quantity * (1 - ordDet.Discount))

Select order.OrderID, order.OrderDate, OrderTotal

' Fill a dictionary with the customers by CompanyName

db.Customers.ToDictionary(Function(cust As Customer) cust.CompanyName)

In addition to all the new language support, we now have keyword Intellisense (finally!)

We have XML Intellisense! What?? That’s right.

And we’ve done some major performance improvements for the background compiler – let us know if you experience any sluggishness for this Beta. (BTW, you should check out Scott's post on Beta2 to avoid some problems with AJAX extensions if you're installing to a machine that has had previous versions of Orcas installed on it or has VS 2005 side by side.)

Also, don’t forget to look for other exciting features around the product that pertain to VB and/or LINQ. For example, Linq to SQL now supports the Like operator! There’s also a new ASP:LinqDataSource control.

So, get the bits while they’re hot!

-Amanda

Shameless Plug (Scott Wisniewski)

VBTeam — Fri, 13 Jul 2007 02:47:00 GMT

If you get a chance, you should check out the August 2007 edition of MSDN Magazine. In addition to its usual array of awesome goodies, this month's edition features a super cool Basic Instincts column, written by me. In it I discuss the design of Query Comprehensions in VB, giving an overview of the basic framework used by the compiler to translate queries into code.

I hope that it should be interesting to anyone who wants to write their own custom query provider, or for anyone who just wants an understanding of how things work under the covers.

If you don't have access to the print version, you can see the online copy here:

http://msdn.microsoft.com/msdnmag/issues/07/08/BasicInstincts/.

Enjoy!

What is the difference between VB 9, VBx and Silverlight? (Scott Wisniewski)

VBTeam — Fri, 08 Jun 2007 04:58:00 GMT

I recently received an email from a customer asking for clarification as to what the difference was between VB 9, VBx and Sliverlight. In particular, it seems as if we have been releasing so much information about cool new stuff that at least a few people have become confused, making them a bit nervous about the future of VB.

The customer had also expressed some concerns about upgrading from VS 2005 to Orcas (VS 2008), particularly because he was considering making an upgrade from VB 6 to VS 2005 and wanted to make sure he would be able to take advantage of Orcas when it was released.

I figured there may be other customers that have similar concerns, and so thought this would make a good blog post, particularly because it's been a while since I've posted anything (J).

As a result I've included a few of the questions he asked (paraphrased) below, along with my answers.

I hope this helps.

What is the difference between VB 9 and VBx? Which one is the next version of Visual Studio?

Visual Basic 9 is the next version of Visual Basic. Visual Basic 10, or VBx as it's sometimes called, is the version of Visual Basic that will follow VB 9. Currently VBx is in very early stages, and is a long way off from production. In fact, most of our development team is actively working on VB 9.

Why on earth would you start talking about VB 10 before you've even released VB 9? This is confusing.

The product cycle for VB 9 is starting to wind down. We recently released Beta 1 of Visual Studio Code Name "Orcas", and are currently working on releasing Beta 2. As the product cycle starts to wind down, our language design team is starting to think about what the "next next" version of the product will look like. They do this mainly as a way to "keep the pipeline moving". If they had to wait until VB 9 was 100% complete before they started thinking about VB 10, then there would end up being a significant delay from when we finished VB 9 until we could start working on VB 10. This is because designing a product, and coming up with a plan to develop it can be extremely time consuming. It requires us to come up with a design, create a schedule, make any necessary organizational changes, and ensure we have the right staffing levels, all before we start coding. By "overlapping" the early design work for VB 10 with the "end game" work for VB 9 we are able to better "bootstrap" the whole process, thus making the transition from one project to the next as smooth as possible.

As our design team comes up with designs they like to release information about them as early as possible. The earlier we can get information out to our customers, the earlier we can get feedback about the things we are doing. This helps us to build the products that actually meet our customers' needs. One thing we've managed to learn over the years is that the best possible way we can learn what it is that our customers want is to engage with them early and often.

As a result, near the end of a product cycle we will release information about our plans for the version of the product to follow the one we are currently working on. This gives our customers the chance to comment on it and let us know what they think. We then take that feedback and use it to develop a more complete plan for what we want to do.

What is VB 10 going to be like? What is this Silverlight Thing I keep hearing about? Is Silverlight a replacement for Visual Studio?

Our plans for VBx and Silverlight are still very rough and are nowhere near complete. As our customers start to use VB 9 and provide us with feedback that data will drive exactly what we end up doing in VB 10. That being said, however, we do have some rough ideas of the things we would like to do.

Silverlight 1.1 is a new light weight version of the .NET Framework that will allow you to develop rich applications that run in a web browser using .NET languages. The basic idea is to allow you to replace client side java script with .NET enabled languages, allowing you to write both the client side and sever side portions of your web applications in the same language. It also allows you to use WPF (windows presentation foundation) and WCF (windows communication foundation) to create extremely rich and interactive web applications in a way that is much easier than what is possible using HTML, Ajax, Java Script, or Flash.

VB 10 is going to be the version of Visual Basic that will follow VB 9 (the "next next version"). It will include new features designed to make VB a really great language for developing SilverLight apps, as well as enhancements to many of the new feature we are delivering in VB 9, such as Linq. You should still be able to do all the things with VB 10 that you could do with both VB 9 and VB 8.

The migration from VB 6 to VS 2005 is non-trivial. If I upgrade to VS 2005 will I able to use VB 9 when it comes out, or will I have to scrap all my work? What about VB 10? Should I be worried about the future of VB?

The transition from VB 8.0 to VB 9.0 should be smooth and relatively painless. We have gone to great lengths to ensure this.

Our plan is to also make the migration from VB 9 to VB 10 equally painless.

Although the migration from VB 6 to VB.NET is a bit tough, we are actively working on making that easier as well. We have been releasing a "VB Interoperability Toolkit" that allows an application to be gradually migrated from VB 6 to VS 2005, rather than requiring the whole thing to be migrated at once.

You can get more information about it here:

http://msdn2.microsoft.com/en-us/vbasic/aa701257.aspx

As far as the future of VB, you should definitely not be worried.

Microsoft is committed to VB, and making it a great language for developing applications for our various platforms. The future of VB should be a bright one!

Partial Methods

VBTeam — Wed, 28 Mar 2007 07:03:00 GMT

About two weeks ago I had the opportunity to attend the product group dinner associated with the Global MVP Summit that was behind held here at Microsoft. Besides a free meal, this also gave me the excellent opportunity to meet with some of our MVPs and discuss their impressions with Visual Studio and all the cool new features we are introducing for Orcas. At the dinner, I had an opportunity to talk with a group of VB MVPS from Japan, who met with me and about 5 or 6 other members of the VB team. While we were talking, a couple of them asked me a few questions about partial methods. Unfortunately, I do not speak Japanese, and so had some trouble answering them. Figuring that written English may be easier to understand than my idiomatic spoken English, I decided to make Partial Methods the topic of my next blog post.

As a result, I've included their questions below along with my answers.

What are Partial Methods?

In a nut-shell, partial methods are a light-weight replacement for events designed primarily for use by automatic code generators. They are declared by creating a private method with an empty body and decorating it with the Partial keyword. The method may then be "re-implemented" elsewhere within its containing class. If the method is implemented, then the compiler will redirect all calls to the partial method to the implementing method. If the method is not implemented in its containing class, then the compiler silently removes any calls to it from the program. They differ from events in several ways, mainly:

A partial method can only have 1 "implementing method", where events may have any number of handlers
The implementing method for a partial method must be in the same class as the partial method its self, where as event handlers can pretty much be defined in any type that has access to the event instance
An event will throw if it has no handlers and is invoked. Usually this requires comparing the event against Nothing to safe guard against an exception. On the other hand, if a partial method does not have an implementing method then the compiler will simply optimize away any calls to it.
The wiring of events is dynamic, which means that handlers can be added and removed from an event at runtime. This can either be done implicitly, using WithEvents variables and Handles clauses or explicitly using AddHandler and RemoveHandler statements. The wiring of partial methods, however, is always done at compile time, and an implementing method is associated with its declaring method by simply writing a method with the same name and signature as the partial method. Once this is done, all references to the partial method are rewritten by the compiler to refer to its implementing method.
Events may be declared with any accessibility (public, private, or friend). Partial Methods, on the other hand must be private. The method that implements it, however, may have any accessibility.

An example use of partial methods is shown below:

'Designer File
Partial Class DesignerGeneratedClass
    Partial Private Sub OnFoo()
    End Sub

    Partial Private Sub OnBar()
    End Sub

    Sub DoSomething()
        OnFoo()
        OnBar()
    End Sub
End Class

'Code Behind File
Class DesignerGeneratedClass
    Public Overridable Sub OnFoo()
        Console.WriteLine("Foo Occured")
    End Sub
End Class

Here we define a class named DesignerGeneratedClass split into two partial classes. It is designed to mimic typical code generation scenarios where one partial class contains designer generated code and another contains user generated code. For example, Windows Forms classes and pages in ASP.NET Web Application Projects utilize this approach. In the designer generated file we define a utility method, DoSomething, that calls two partial method declarations OnFoo and OnBar. The user file implements OnFoo, but not OnBar. When the VB compiler processes this class, it notices this and emits a body for DoSomething() that only calls OnFoo().

What are Partial Methods useful for?

For most applications, events are almost always a better choice than partial methods due to their increased flexibility. However, there are some scenarios where they come in handy. A couple of them are listed below:

In automatic code generators

Partial methods enable code generators to write extremely flexible code by creating a lot of "hooks", where developers can provide their own custom functionality that integrates into the "boiler plate" code created by the generator. Because the hooks are optimized away if they aren't used, no performance penalty is introduced by defining them. This is really useful if generated code needs to be used in high performance scenarios. For example, partial methods are used by the DLINQ designer for exactly this purpose. Developers wishing to invoke custom code on their data objects when properties are set can do so without requiring all users of DLINQ to suffer performance problems.
To increase the readability of code that uses conditional compilation constants.

Consider the following code that uses conditional compilation constants in VB.

Class UglyConditonalCompilationCode

#If DEBUG Then
    Private Sub LogMessage(ByVal s As String)
        Console.WriteLine(s)
    End Sub
#End If

    Sub DoStuff()
        DoFirstThing()
#If DEBUG Then
        LogMessage("Did first thing")
#End If
        DoSecondThing()
#If DEBUG Then
        LogMessage("Did second thing")
#End If
        DoThirdThing()
#If DEBUG Then
        LogMessage("Did third thing")
#End If
    End Sub
End Class

This code is obviously difficult to read. However, using partial methods it is possible to make the code much more readable:

Class PrettyConditonalCompilationCode
    Partial Private Sub LogMessage(ByVal s As String)
    End Sub

#If DEBUG Then
    Private Sub LogMessage(ByVal s As String)
        Console.WriteLine(s)
    End Sub
#End If

    Sub DoStuff()
        DoFirstThing()
        LogMessage("Did first thing")
        DoSecondThing()
        LogMessage("Did second thing")
        DoThirdThing()
        LogMessage("Did third thing")
    End Sub
End Class

Are Partial Methods Some Form Of AOP (Aspect Oriented Programming)?

No. Partial methods do share some things in common with Aspect Oriented Programming in that partial methods offer a way of associating "hooks" with custom code. However, unlike AOP systems partial methods require extension points to be explicitly defined by the customer. AOP systems allow developers to "weave in" functionality into code that hasn't had explicit hooks defined. Usually they do this by specifying some declarative search strings that describes the places where the hooks should be applied. The compiler is then responsible for finding all the appropriate "extension points" to apply the hooks to and injecting any necessary method calls. Partial methods in VB do not do this.

Extension Methods Best Practices (Extension Methods Part 6)

VBTeam — Sun, 11 Mar 2007 02:36:00 GMT

This is the sixth installment in my series of posts about extension methods. You can find links to the rest of the series here.

Today I am going to talk about some best practices for using extension methods. Most of this content is geared toward authors of class libraries designed for wide spread consumption. Developers of such libraries often need to worry about things like making their API's future proof, and finding ways to extend their libraries while still preserving backwards compatibility. In most real world applications these suggestions can (and quite frankly should!) be completely ignored. However, if you are in the business of creating components or libraries used by many developers, than heeding this advice should help to ensure that your consumers, particularly those using VB, have a pleasant experience with your API.

1. Read the .NET Framework Class Library Design Guidelines

The .NET Framework Class Library Design Guidelines, available here, provide guidance on how to write highly usable, secure, and extensible class libraries for the .NET Framework. Also, Brad Abrams and Krzysztof Cwalina wrote a book on how to do this. You should check them out.

2. Be wary of extension methods

For an application programmer, extension methods are an incredibly powerful and expressive tool. They enable convenience, extensibility, and an improved intellisence experience. However, many of the features that make extension methods so useful for library consumers can be problematic for class library authors. In particular, there are 2 primary issues I outline below that you should be aware of when using extension methods in class libraries, particularly for mass-market libraries that need to maintain backwards compatibility across multiple releases.

The first issue is that extension methods have "hide-by-name" semantics with instance members on a type. This means that any accessible instance member on a type will always shadow any extension methods with the same name, even if the extension method is a better fit (see part 4 for details). As a result, if an instance member is ever added to a type with the same name as an extension method, then the extension method can be rendered uncallable. This can make extension method libraries somewhat fragile.

The second issue is that an extension method author cannot prevent other programmers from writing conflicting extensions. Instance method authors can mark their classes as "notinheritable" and prevent them from being augmented by derived classes. Similarly, methods marked as "overridable" in abstract base classes can be marked as "notoverridable" when they are overridden in a derived class, disallowing them from being overridden by classes further down in the hierarchy. Instance methods cannot be overridden by extension methods. These things give class library authors certain degrees of certainty about which instance methods will be called in which situations. Unfortunately, however, extension method authors have no such guarantees. If a library user brings a third party extension method with the same name as yours into scope then that method may be preferred over yours. As a library author there is nothing you can do to prevent this.

As a result, you should be cautious when adding extension methods to your class libraries unless either:

These risks are unimportant (as is the case with most internal libraries), or
You take steps to mitigate them as outlined in the rest of this article

3. Put extension methods into their own namespace

One simple way to improve the robustness of your extension method library is to put extension methods into their own namespace. This is the strategy employed by the 3.5 version of the .NET Framework. By putting extension methods into their own namespace you enable consumers to include or exclude them separately from the rest of your library. This makes them pluggable, allowing users to easily replace extension method implementations with other implementations if they wish (which is at the heart of the LINQ provider model). This in turn then makes it easier for them to resolve any conflicts that may arise (see part 2 for information about extension method precedence levels).

4. Think twice before extending types you don't own

If you only write extension methods for types you own, then you never have to worry about your extensions being broken by changes to the type being extended. On the other hand, if you are extending other peoples types than you are essentially at their mercy. Alternatively, you can minimize this risk by choosing names that are unlikely to be used by someone else, or by minimizing the total number of extension methods you define (i.e reducing surface area). One technique for doing this may be to write one extension method that converts the underlying object to a different type that is controlled by you.

5. Prefer interface extensions over class extensions

This may seem like odd advice, given that the The .NET Framework Class Library Design Guidelines referenced above state that you should "prefer classes to interfaces". However, the reasons for advocating interface extensions over class extensions are identical to the reasons for advocating the use of classes over the user of interfaces in that document: interfaces cannot be safely versioned. In other words, an interface cannot be changed without requiring every class that implements it to be modified. This means that, for the most part, as a class library author you can treat interfaces as immutable types (if they do change, all their clients will be broken anyways, so you can't make the problem any worse). Classes, on the other hand, can add new methods without breaking their clients, which is why the design guidelines recommend them (at least they could prior to the introduction of extension methods, and so to be safe you should assume that other class library authors may continue to follow that convention). As a result, interface extensions are inherently less fragile than class extensions.

This isn't perfect, as interface extensions can be visible from instances of implementing classes, which may then change in future versions by adding new methods. However, these issues can always be worked around by casting any such classes to instances of the interface. With class extensions, such a workaround may not be possible.

6. Be as specific with the types you extend as possible

Extensions on less specific types are more likely to be broken by external change than extensions on more specific types. This is because the higher a type is in the hierarchy, the more types there are that derive from it. An extension method on type "Object" can be broken by the introduction of any member to any type anywhere. An extension method on "string", on the other hand, can only be broken by changes to string or other extension methods. Therefore, by preferring more specific types, you can reduce the likely hood of other people's changes impacting your API. This is a little at odds with item #5, as interfaces are by definition less specific than classes. As a library author you would have to find the right balance between them.

7. Please ignore this advice where it is not appropriate

I mentioned this at the beginning of the post, but I thought it was worth pointing out again: for most programs you should ignore this advice. Adding extension methods to any type is a great way to improve productivity and simplify code. You should do this wherever it feels beneficial to you, without worrying about any of these details. However, if you need to write an API that can be consumed by a lot of programmers (say thousands or even millions), then I think it's worthwhile for you to consider these constraints in your designs.

That's all I have for today. Stay tuned for my next post where I will break away from extension methods and start to talk about some of the other cool features we are introducing into the language.

March 2007 Orcas CTP Available

VBTeam — Thu, 01 Mar 2007 05:46:00 GMT

The March 2007 Orcas CTP is now available for download.

You can see Soma's anouncement about it here.

This is the first Orcas CTP to include new VB 9.0 features and is the first update of VB LINQ since last year's May 2006 LINQ CTP.

Amongst a lot of other really cool Orcas stuff, this CTP includes previews of the following VB 9.0 features:

Basic Query Support
Object Initializers
Extension Methods
Type Inference
Anonymous Types
XML Literals
XML Access Members
Some Really Cool Intellisence Enhancements

You can download it here.

Also, downloading the CTP is a great way to checkout the things I've been talking about in my recent posts about extension methods.

Extension methods and Generics (Extension Methods Part 5)

VBTeam — Fri, 16 Feb 2007 00:40:00 GMT

This is the 5th installment in my series of posts about extension methods. You can find links to the rest of the series here. Originally I had planned on discussing extension method versioning issues, but I've decided to postpone that topic to my next post and talk about extension methods and generics instead.

In Orcas we've introduced a new set of rules for the way we deal with generic extension methods that differs significantly from the way we deal with regular generic methods. When binding against extension methods we now perform generic type parameter inference in two passes instead of one. During the first pass we infer types for type parameters referenced by the first argument and during the second pass we infer types for any type parameters referenced by subsequent arguments. Internally we have been referring to this as "partial type inference" in our discussions about it. As an example, consider the following:

Imports System.Runtime.CompilerServices

Module M1
    Interface IFoo(Of T1, T2)
    End Interface

    <Extension()> _
    Public Sub Bar(Of T1, T2, T3)(ByVal x As IFoo(Of T1, T3), ByVal y As T2, ByVal z As T3)
    End Sub

    Sub Main()
        Dim x As IFoo(Of Integer, String) = Nothing
        x.Bar("Hello", 2)
        Bar(x, "Hello", 2)
    End Sub
End Module

Using the Whidbey type inference algorithm the instance method call to Bar in Main would result in a compile time error. Attempting to resolve all types in one pass, the compiler would infer two conflicting types for T3, one from parameter X and another from parameter Z. With Orcas, however, the extension method call to Bar will not generate an error. Instead, the compiler will first infer types for T1 and T3 from parameter x and then substitute their values back into the procedure's signature. During the second pass of type inference the compiler will then treat the method as if it was a method with only one type parameter rather than a method with three type parameters. A value will be inferred for T3 from Z and then a conversion will be inserted to convert the integer arguments supplied to Y into the string value expected by the procedure.

Although this may seem like a complicated and perplexing rule, there is a bit of method to our madness. In particular it enables us to:

Maintain transparency between extension methods and instance methods
Avoid generating misleading intellisence information.
Produce a better query-editing experience

Each of these reasons is discussed in detail below:

Extension Method Transparency

To see why the first reason is true is, let's consider the following:

<Extension()> _
Sub InsertTwice(Of T)(ByVal x As ICollection(Of T), ByVal y As T)
x.Add(y)
x.Add(y)
End Sub

Here we define an extension method named "InsertTwice" that applies to all implementations of the generic ICollection(of T) interface. Its implementation is rather trivial. That thing about it that is interesting is that its type parameter T is, in a sense, more of a "generic type parameter" than a "generic method parameter". Its primary purpose is to define the types of the objects to which the method is applicable, rather than to define the signature of the method itself. The fact that the there is a dependency between the method's signature and its "containing" class is a peculiarity of the method, not of the type parameter. The parameter's primary function is still to define the type. An alternative way to look at it is to consider how the method would look if it was defined as an instance method rather than as an extension method. Had "InsertTwice" been defined as instance method T would almost certainly be defined as a type parameter on a class rather than as a type parameter on a method. The need for T to be defined as a method parameter is simply just a side effect of the syntax to define extension methods. In fact, using this point of view it becomes clear that all type parameters referenced by the first argument of any extension method really are generic type parameters rather than generic method parameters. The goal of the compiler then, by splitting the inference up into two distinct steps, is really to restore things back to their correct state. The generic type parameters get treated as type parameters (they are inferred solely from the "me" parameter), and the generic method parameters get treated as method parameters (they are inferred from the method's arguments).

This does have some interesting implications. Mainly, it is now possible to invoke a generic method with some arguments explicitly provided and other arguments implicitly inferred. In particular, any type parameters that are determined to represent generic type parameters (because they are referenced by the first argument) are always implicitly inferred from the type of the object that the method was invoked on. The remaining type parameters, which are treated as generic method parameters, may then be explicitly supplied by the caller if necessary. However, the old Whidbey rules still apply to the group of parameters that are determined to belong to the method. Effectively, although it's possible to implicitly infer the "type" parameters and explicitly supply the "method" parameters, it is not possible to implicitly infer some method parameters and explicitly supply others.

Intellisence Usability

Moving on to reason #2 in our list above, this also fixes a small issue with intellisence. At the heart of our intellisence design is the principal that we never guide the user towards generating compiler errors. If an item shows up in a completion list in a given context then it is valid to use that item in that context. When we show information in a tool tip it is always up to date and accurate. This is really just an example of the IDE trying both to be nice and to avoid looking stupid. If we were to offer you something and then start to complain immediately after you selected it, then we would appear to not only be rude, but also to be stupid. This also means you can trust what the compiler tells you. If our "find symbol" says something doesn't exist or our "find all references" says something isn't used, then it doesn't exist or it isn't referenced. Similarly, if something does exists, or is being referenced somewhere in your code than we will report those things to you. If we show a tool tip, then the data in that tool tip is correct. At least that's how we design things to be. Realistically there always will be bugs that slip through the cracks, or things that aren't 100% perfect. However, we try our best to make the information that we give you as useful as possible.

Before we implemented the two step process for generic type inference in intellisence, some of the information we would show in intellisence was a bit misleading. Technically it was accurate but it was much less useful than it could be. To illustrate this, let's consider our "InsertTwice" example from above. If we were to invoke the method using the following code snippet:

Sub Main()
Dim x As New List(Of String)
x.InsertTwice(
End Sub

Then without our new rules we would end up showing a parameter info tool tip that looked like the following:

This, however, is a bit misleading. It indicates that InsertTwice is a generic method that can take an argument of any type T. This is, however, not true. The type of the argument is actually fixed to be string. Supplying any argument that was not String would yield a generic type inference error. More importantly, this error would then lead the author of this code to believe that he could fix the problem by explicitly providing the type of T:

x.InsertTwice(Of String)

However, this would only end up generating yet another generic type inference error, mainly because types inferred from x would then conflict with types inferred from y. Obviously this hurt the usability of intellisence. With our new rules, however, we end up showing a parameter info tooltip that looks like this:

This is clearly much more useful.

Improved Query Support

The third, and perhaps most important, reason behind this decision is that it had a tremendous positive impact on our ability to support a good experience around using LINQ with VB. To see why, let’s consider a simple example:

Imports System.Linq

Module M1
    Sub Main()
        Dim xs As Integer() = {1, 2, 3, 4}
        Dim q = From x In xs Where x Mod 2 = 0 Select x
    End Sub
End Module

Here we define a simple query that selects all even integers out of an array. When processing this query the compiler converts into the equivalent of the following code:

Dim q = xs.Where(Function(ByVal x) x Mod 2).Select(Function(ByVal x) x)

Which invokes 2 extension methods, one called Where that takes in a lambda that corresponds to the contents of the where clause, and another called select that takes in a lambda that corresponds to the contents of the select clause. As these queries are being typed the compiler will provide intellisence within each clause. Doing so, of course, requires identifying the element type of the collection being queried over so that its members may be appropriately shown in intellisence completion lists. Our new typing rules help make this easy. If we look at the signature of the Where method we can see why this is:

Public Function Where(Of T)(ByVal source As IEnumerable(Of T), ByVal predicate As Func(Of T, Boolean)) As IEnumerable(Of T)

It defines an extension method that is applicable to all implementations of the IEnumerable(of T) interface, taking in delegate that maps from type T to Boolean and returns another IEnumerable of the same type. If the old Whidbey rules were used to perform type inference on the call to Where, it would not be possible to determine the element type T of the collection until the entire where clause of the query had been processed, because the body of the where clause needs to be converted into a lambda and then wrapped up in a delegate type and passed off to the procedure as an argument. However, in order to assist query authors in writing a where clause, the IDE must be able to deduce the element type of the collection. This creates a obvious chicken-and-egg-situation: it becomes necessary to determine the value of T in order to be able to determine the value of T.

However, with our new rules this problem doesn't exist. With the new rules we can determine the element type of a collection just by looking at the collection its self, without expliciting having to bind all sub expressions first. This, of course, then makes it easy for us to provide accurate and useful intellisence inside our queries.

Caveats

Unfortunately, this does introduce a few minor issues that you need to be aware of. Mainly:

Type parameters referenced by the first argument of an extension method may not be constrained by other type parameters that are not referenced by the first parameter of an extension method. This means that while the following extension methods would be legal:

<Extension()> _
Sub M1(Of T1, T2)(ByVal x As T1)
End Sub

<Extension()> _
Sub M2(Of T1, T2 As T1)(ByVal x As IFoo(Of T1, T2))
End Sub

that this one, on the other hand, would not:

<Extension()> _
Sub M3(Of T1, T2 As T1)(ByVal x As T2)
End Sub
C# does not implement these rules, so any extension methods defined in C# that violate the above restriction will not be visible to VB programmers.

In general, however, we feel that these restrictions are largely outweighed by the benefits these rules introduce.

Side Note

On a side note, the instance method call I mention in my first example will also no longer be an error in Orcas. This, however, has to do with a different change we are introducing to resolve type inference conflicts that I won't delve into with this post. It is sufficient, however, to note that the rules for type inference in the instance method case will continue to use an "infer-everything-at-once-approach", where as extension methods will use the two step algorithm I outline here.

In any case, I think that's enough for today.

Stay tuned for my next post, where I will discuss some best practices for using extension methods in your programs.

Extension methods and late binding (Extension Methods Part 4)

VBTeam — Thu, 25 Jan 2007 01:09:00 GMT

This is the fourth installment in my series of posts about extension methods. You can find links to the rest of the series here.

Today I'm going to talk about extension methods and late binding. Essentially there isn't much to say about it, other than the fact that we don't support late bound execution of extension methods. For the most part this isn't a big deal as one of the primary benefits of extension methods is its interaction with intellisence which doesn't work in late bound scenarios anyways. Unfortunately, however, there is one big side effect of this decision that you need to be aware of when authoring extension methods. Mainly, we do not allow extension methods to be called off of any expression that is statically typed as "Object". This was necessary to prevent any existing late bound code you may have written from being broken by extension methods. Too see why, consider the following example:

Class C1
    Public Sub Method1()
        Console.WriteLine("Running c1.Method1")
    End Sub
End Class

Class C2
    Public Sub Method1()
        Console.WriteLine("Running c2.Method1")
    End Sub
End Class

Module M1
    Public Sub Main()
        Dim x As Object = Nothing
        If (SomeCondition()) Then
            x = New C1
        Else
            x = New C2
        End If
        x.Method1()
    End Sub
End Module

Here we have a program which uses late binding in order to invoke the method "Method1" on an object that is either of type "c1" or of type "c2". It does this because the static type of the variable "x" is declared as object, which causes the compiler to resolve any calls to "unknown" methods as late bound calls that will be resolved at runtime based on the dynamic type of the object stored in "x". Extension methods, however, are always fully resolved at compile time. As a result, if we were to add an extension method defined on Object, like so:

<Extension()> _
Public Sub Method1(ByVal x As Object)
Console.WriteLine("Running Extension method m1.Method1")
End Sub

Then the act of simply importing the namespace containing the method would cause the formerly late bound method call to Method1 to be transformed into an early bound call to the extension method. This would not be good, as it would silently change the meaning of the program, which would have the potential of making extension methods very, very dangerous. In fact, we explicitly disallow this in early bound scenarios by always having instance methods defined on a type shadow any extension methods defined on it with the same name. This enables you to import extension methods into your existing code without having to worry about things blowing up in your face.

In the case of late bound calls, however, we can't use the same shadowing semantics that we do with early bound method calls because we don't know the actual type of the object we will be calling the method on, so we don't have a list of methods we can check against at compile time. As a result, the only way we could prevent extension methods from completely breaking existing late bound code was to prevent them from being used on anything typed as object.

This has the effect of slightly changing the meaning of an extension method defined on object. Consider the following non-object extension method:

<Extension()> _
Public Sub Method2(ByVal x As System.Windows.Forms.Control)
End Sub

Here the declaration of "Method2" implies that the method is an extension method applicable to the type System.Windows.Froms.Control and any class that derives from it, such as TextBox or DataGridView. In the case of "Method1", however, the method declaration implies that it is applicable to "all types except object". This is a little unfortunate, as it is an inconsistency in the language, but we felt it was much better in this case to be safe than it was to be consistent.

That's all I have for today. In my next post I'll talk about extension methods and generics.

Extension Methods (part 3)

VBTeam — Fri, 19 Jan 2007 08:50:00 GMT

In my previous 2 posts I talked about some of the benefits of extension methods and then delved into the details of our new binding rules for consuming them in your programs. Today I'm going to talk about some perils to be aware of when defining extension methods.

First, however, I'm going to dig a little into the mechanics used by the compiler for evaluating extension method calls. Essentially, whenever the compiler detects a call to an extension method, it simply translates it into a call to the underlying module method, passing in the call's receiver as the method's first argument.

If we take the following simple example:

Delegate Sub DelegateSub()

<Extension()> _
Sub Times(ByVal x As Integer, ByVal d As DelegateSub)
    For i = 1 To x
        d()
    Next
End Sub

with the following call site:

Sub SayHello()
Console.WriteLine("Hello")
End Sub

Sub Main()
Call 3.Times(AddressOf SayHello)
End Sub

The compiler will then emit code that is equivalent to the following:

Sub Main()
Times(3, AddressOf SayHello)
End Sub

For the most part this transformation is simple and automatic. In fact, we've taken great pains to ensure that the experience of calling an extension method on an object is as smooth as possible. Unfortunately, however, with value type extensions things get a little bumpy. To illustrate this, let's consider the following slightly more complex type:

Structure Vector
    Public X As Integer
    Public Y As Integer
    Public Z As Integer

    Public Sub Scale(ByVal factor As Integer)
        X *= factor
        y *= factor
        z *= factor
    End Sub
End Structure

Here we define a method called "Scale" that mutates the current Vector, multiplying each of its members by the given scaling factor. As an instance method, this works fine. However, let's suppose we were to try and define "Scale2" as an Extension method:

Module Module1
    <Extension()> _
    Public Sub Scale2(ByVal [me] As Vector, ByVal factor As Integer)
        [Me].X *= factor
        [Me].y *= factor
        [Me].z *= factor
    End Sub
End Module

Calling this method will not have the same results as calling Scale. In particular, if we were to execute the following code:

Sub Main()
    Dim v As Vector

    v.X = 1
    v.Y = 1
    v.Z = 1

    Console.WriteLine("v.x={0}, v.y={1}, v.z={2}", v.X, v.Y, v.Z)
    v.Scale2(2)
    Console.WriteLine("v.x={0}, v.y={1}, v.z={2}", v.X, v.Y, v.Z)
End Sub

We would see that the value of v is unchanged after the call to Scale2. The reason for this is because value types have "value semantics", which means that unless they are passed as "byref" parameters they are copied every time they are passed to a procedure. As a result the extension method ends up mutating a copy of "v" rather than "v" itself. To fix this we need to declare the extension method with its "me" parameter declared "byref".

<Extension()> _
Public Sub Scale2(ByRef [me] As Vector, ByVal factor As Integer)
    [me].X *= factor
    [me].Y *= factor
    [me].Z *= factor
End Sub

The "Scale2" extension method will then behave identically to the instance method version.

Unfortunately, however, that doesn't mean extension methods with "byref" me parameters are without their own issues. This is especially true when defining extension methods on reference types. As an example, consider the following:

Imports System.Runtime.CompilerServices

Class C1
End Class

Module M1
    <Extension()> _
    Sub WeirdExtensionMethod(ByRef x As C1, ByVal y As C1)
        x = y
    End Sub

    Sub Main()
        Dim x As New C1
        x.WeirdExtensionMethod(Nothing)

        If (x Is Nothing) Then
            Console.WriteLine("X has magically become null. How did this happen?")

End If
End Sub
End Module

Here we define an extension method that when called changes the reference of the variable it was called on. This has the potential of being very alarming to consumers of the method (generally calling a method on object doesn't cause the variable that holds the reference to suddenly point to another object). With extension methods, unfortunately, it is now possible to write code that does this.

As we started development on the feature we briefly debated fixing both of these issues by requiring all value type extensions to have a byref me parameter and all reference type extensions to have a byval me parameter. However, enforcing this rule also meant we would have to make it illegal to define unconstrained generic extension methods like the following:

<Extension()> _
Sub GenericExtensionMethod(Of T)(ByVal x As T)
'...
End Sub

However, we felt that this would unduly hurt interoperability between VB and other languages on the .NET platform that did not employ these restrictions. This was mainly because in the absence of these restrictions it is very natural to define methods like the one shown above. If we prevented these methods from being used in VB would then end up throwing out the vast majority of generic extension methods written in those languages.

Unfortunately, this does mean that extension method authors need to be a little bit more cognizant of the methods they create. On the other hand it also enables VB programmers to use libraries written in other languages by programmers who may not be aware of any of the peculiarities of VB. Given that our design goals were centered on consumption rather than authoring, however, we felt this was a fair exchange.

In any case, stay tuned for my next post, where I will discuss Extension Methods and Late Binding.

Extension Methods (part 2)

VBTeam — Fri, 12 Jan 2007 00:04:00 GMT

In my previous post I gave a high level overview of some of the benefits of using Extension Methods in VB 9.0. Today I'm going to delve into some of the details about how to define extension methods and then use them in your programs.

Defining Extension Methods

You can define an extension method by creating a method in a VB module and decorating it with the System.Runtime.CompilerServices.Extension attribute. The type of the methods first parameter specifies the type the method extends, and the remaining arguments indicate the method's signature. In general, we allow an extension method to be defined on any type that can be represented in a VB signature, with the exception of param arrays, optional arguments, and generic type parameters to (because modules may not be generic). Specifically, this enables you to define extension methods on any of the following types:

Classes (Reference Types)
Structures (Value Types)
Interfaces
Delegates
ByRef / ByVal arguments
Generic method parameters
Arrays

Consuming Extension Methods

In order to consume an extension method, you simply need to bring it into scope. The method will then be visible in intellisence and callable as if it was an instance method. This is a rather simple statement, but it has several interesting implications. In particular, this is a distinct departure from the behavior we implemented in the May 2006 Linq CTP, where we required each type that defined extension methods to be individually imported before its extensions could be used. Although this had some advantages, such as providing fine grained control over extension method visibility, it also suffered from numerous drawbacks.

One big problem was the fact that it was different than C#, which makes extension methods visible by importing the namespace that contains the types that define them. To see why this is an issue, consider the following 2 example C# class libraries:

Example 1:

namespace CSharpExtensionMethodLibrary
{
    static class Extensions1
    {
        public static void ExtensionMethod1(this string x)
        {
        }
    }

    static class Extensions2
    {
        public static void ExtensionMethod2(this string x)
        {
        }
    }

    static class Extensions3
    {
        public static void ExtensionMethod3(this string x)
        {
        }
    }

    static class Extensions4
    {
        public static void ExtensionMethod4(this string x)
        {
        }
    }

    static class Extensions5
    {
        public static void ExtensionMethod5(this string x)
        {
        }
    }
};

Example 2:

namespace CSharpExtensionMethodLibrary
{
    static class Extensions
    {
        public static void ExtensionMethod1(this string x)
        {
        }

        public static void ExtensionMethod2(this string x)
        {
        }

        public static void ExtensionMethod3(this string x)
        {
        }

        public static void ExtensionMethod4(this string x)
        {
        }

        public static void ExtensionMethod5(this string x)
        {
        }
    }
};

Here the first example defines an extension method library with the extensions defined in several different static classes all in the same namespace. The second example defines the same extension methods concentrated into a single class. From the point of view of a C# consumer, these libraries are equivalent. To consume them, a C# program simply needs to import their containing namespace. For a VB consumer in the May 2006 Linq CTP, however, these libraries are very different. To consume the first one, a VB programmer would need to add 5 imports statements to his code, where as with the second one he would only need to add one.

Using Example 2 from C#:

using CSharpExtensionMethodLibrary;

class C1
{
    void Main()
    {
        string x = "";
        x.Extension1();
        x.Extension2();
        x.Extension3();
        x.Extension4();
        x.Extension5();
    }
}

Using Example 2 from VB in the May 2006 CTP:

Imports CSharpExtensionMethodLibrary.Extension1
Imports CSharpExtensionMethodLibrary.Extension2
Imports CSharpExtensionMethodLibrary.Extension3
Imports CSharpExtensionMethodLibrary.Extension4
Imports CSharpExtensionMethodLibrary.Extension5

Module M1
    Sub Main()
        Dim x as String = ""
        x.Extension1()
        x.Extension2()
        x.Extension3()
        x.Extension4()
    End Sub
End Module

Obviously this has the potential of causing API usability problems for VB programmers consuming C# extension methods.

However, by restricting our rules to only allow extension methods to be defined in modules and changing the rules for extension method visibility to include "any extension method in scope", we were able to solve this problem and achieve parity with C# in a way that meshed well with existing VB language concepts. This works because VB modules have the property of "hoisting" there members into their containing namespace, so importing a namespace will also bring the extension methods defined in its types into scope. Therefore, by treating C# static classes as VB modules (for the purposes of extension methods), we can ensure that VB customers have an API usability experience that is comparable to C#.

Using Example2.dll from VB in Orcas:

Imports CSharpExtensionMethodLibrary

Module M1
    Sub Main()
        Dim x = ""
        x.Extension1()
        x.Extension2()
        x.Extension3()
        x.Extension4()
    End Sub
End Module

However, we still retain the ability to import a module directly, so the fine grained control offered by the May 2006 CTP is available for anyone who needs it. We've also introduced shadowing rules that give you some degree of control in resolving conflicts between extension methods. More explicitly, we break extension methods into a series of precedence levels based on the mechanism used to bring them into scope. In the event of a conflict between two methods with identical signatures and different precedence levels, we will pick the one with the higher precedence level. The complete list of these levels is shown below (items with lower numbers have higher precedence).

Extension methods defined inside the current module (if there is one)
Extension methods defined inside types in the current namespace or any of its parents, with child namespaces having higher precedence than parent namespaces
Extension methods defined inside any type imports in the current file
Extension methods defined inside any namespace imports in the current file
Extension methods defined inside any project-level type imports
Extension methods defined inside any project-level namespace imports

In the event that these shadowing rules are not enough to resolve ambiguities you may always bind to a particular method by using the old Whidbey-Style shared method syntax (i.e. StringExtensions.Speak(x) as opposed to x.Speak()).

I think that is enough for today. Fortunately, I've only scratched the surface. In my next several posts I will dig into some of the issues you need to be aware of when writing extension method libraries, including:

Extension methods on Value Types
VB Late Binding and Object Extensions
Type Inference rules for Generic Extension Methods
Extension method Versioning Issues

Extension methods (part 1)

VBTeam — Fri, 05 Jan 2007 22:59:00 GMT

Hi.

I'm Scott Wisniewski, a dev on the VB Compiler Team. I've been here for a while now (about a year and a half), but this is my first blog post. I've been spending the past seven months or so working on Orcas, and finally decided it would be a good time to come up for some air, talk about what I've been working on, and start to actually make a dent against my blogging commitments.

I figured the best place to start is with my favorite feature: extension methods. If you didn't know this already, one of the new features we are adding to VB 9.0 is Extension Methods, which provide a very powerful and elegant way to inject your own custom functionality into other people's types. In particular, through a great deal of compiler magic, Extension methods enable you to create a method in a module decorated with an attribute and have that method appear as if it was an instance method defined on another type. Here is a simple example, where we define an extension method that adds a method called "Speak" directly to the string class.

Imports System.Runtime.CompilerServices
Imports System.Speech.Synthesis

Module Module1
    <Extension()> _
    Sub Speak(ByVal x As String)
        Using synth As New SpeechSynthesizer()
            synth.Speak(x)
        End Using
    End Sub

    Sub Main()
        Dim x = "Hello World"
        x.Speak()
    End Sub
End Module

This method then wraps up the speech API, causing the string to be spoken through the computer's speakers.

If we examine the method definition, it looks more or less exactly like any run-of-the-mill helper routine, with the notable exception of it being decorated with the "System.Runtime.CompilerServices.Extension" attribute. The use of this attribute instructs the compiler to treat the method as an extension method, which in turn causes the new helper method to appear as if it was a pre-defined instance method automatically available to users of the string class.

If we compare this to the old way of doing things, the feature really starts to show its elegance. In Whidbey, helper routines that operated on common types(particularly non-extensible types like "string", "sealed classes", and interfaces) often suffered from a few draw backs. Mainly:

They were not easily discoverable through intellisence
They use an awkward, counter-intuitive syntax

Intellisence is, in my opinion, one of the greatest programming tools ever invented. Beyond the obvious productivity gains it introduces, is the tremendous discoverability it provides. Many programmers (myself included) often find themselves dealing with objects they have either never seen before or are generally unfamiliar with. In these cases, Intellisence proves to be incredibly valuable, because it allows you to effortlessly discover how these objects work. If you want to know what data is stored in an object, or what operations it is capable of performing, you simply just need to type a "." after the object name or the operation that provided the object to you and intellisence will sweep in and provide you a nice organized picture of what the object is capable of.

With custom-written shared utility methods in Whidbey, however, this kind of discoverability is not possible. Although intellisence will provide parameter info about how to call these methods, and will provide code completion if you start to type their names, it provides little in the way of help for people who do not know that these utility methods exist and are available for their consumption. In particular, calling a utility method uses a different syntax than calling an instance method (Speak("Hello World") versus "Hello World".Split()), and so while typing "." after a string will display "Split" amongst the list of possible choices, and parameter info will be provided after typing "Speak(", the user of an API has to know, ahead of time, weather the function he or she is calling is a shared utility method written by a third party or an instance method provided directly by the class author in order to get help from the compiler about how to use it.

Extension methods in Orcas, however, fix this problem by merging third party utility methods with canned instance methods written by class authors, essentially making utility methods just as discoverable as the built-in ones. The screen-shot below shows an example of this in action:

A programmer in Whidbey, who may not have been aware that a helper method named "Speak" existed, would receive immediate feedback in Orcas about its existence. Personally, I think this is revolutionary.

Also, instance methods have a distinct advantage over shared utility methods in that they make it much easier to chain operations together. As an example, consider a task which requires Translating a string from English to Spanish, running it through a grammar checker, and then finally sending it out as the body of an Email message. Accomplishing this using helper methods may look something like this:

SendEmailToCustomer(TranslateToSpanish(RunGrammerChecker("Extension methods are cool".) ) )

This has the problem, however, of being somewhat counterintuitive. The operations are specified in the opposite order in which they are executed, which makes the code both harder to write and more difficult to understand. If these helper methods were written as Extension methods, however, they could be called just like instance methods allowing users of the API to write something like this:

"Extension methods are Cool".RunGrammarChecker().TranslateToSpanish().EmailToCustomer()

This is easier to write, because intellisence provides better completion lists, and easier to read because the operations are specified in the same order they execute.

In any case, I hope this is enough to wet your appetite for the coolness of extension methods. In my next post, I'll dig a bit more into the details of how they work, the rules for defining them, and how they are used.