Two language features, Dynamic Interfaces and Dynamic Identifiers, were cut from VB 9. New features that are being added in their place include Partial Methods. While partial methods share many of the same use cases as events, they have very different implementations.
The VB Team writes,
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.
Compared to events, partial methods have a lot of limitations. Unlike an event, which can have multiple handlers, partial methods are limited to a single implementation. And while the implementation can be in a separate partial file, it still must be in the same class. Finally, there are not any runtime equivalents to the ability to add and remove handlers at runtime.
So why use partial methods? Because they are much faster. Cycles must be burned raising an event, even no handlers are actually attached. If they are attached, a delegate must be invoked for each handler.
Partial methods, if they are implemented, always use a faster non-virtual call. If they are not implemented, the compiler completely eliminates any code calling the method. When used with a code generator that exposes a lot of hooks, the potential performance gains are significant. According to Scott Wisniewski, Software Design Engineer of the VB Core Compiler Team,
We needed to add Partial Methods in order to support the DLinq Designer. Some of our earlier CTP’s utilized events to make the properties generated for DLINQ objects customizable. However, the DLinq team did some performance investigations of this and found the performance overhead of events in those scenarios to be unacceptable. As a result, we added partial methods to enable DLINQ to be customizable without hurting performance.
Earlier we mentioned that Dynamic Interfaces and Dynamic Identifiers were cut. These features are not necessarily dead, though they will not be making the Orcas release. Scott Wisniewski writes,
We cut Dynamic Interfaces mainly for resource reasons. In particular, the amount of time we were given to implement Orcas did not enable us to implement all of the features we had originally planned. As a result, we needed to sit down and figure out which features we would be able to implement and which ones we would not. Unfortunately, because Dynamic Interfaces were not necessary for enabling the core LINQ scenarios we ended up cutting them. Currently we are still evaluating which features we want to implement in the version of Visual Studio following Orcas.
Users can submit suggests for the post-Orcas release to by logging a suggestion on the Microsoft Connect site or through the VB Team Blog.
