Just Say NO to Extending the “My” Classes in VB 2005, Redux

Last month I wrote a really long blog about the “My” Classes in VB 2005 with two hypothetical scenarios regarding the future of .NET and development because of the introduction of the “My” classes. I had a lot of fun writing it, but afterward realized it was far too long to get across my key points. That is why I am revisiting the subject today.

The “My” classes is a beautiful and incredibly useful addition to Visual Basic, and I applaud Microsoft for thinking of it. In hindsight, it is obvious, but isn’t that true of all the best innovations?

However, because the “My” classes can be extended, I believe there will be thousands of competing, incompatible implementions all crammed into that one single namespace path. The concept and implementation of namespaces in .NET was incredibly elegant and solved many problems, but “My” class extensions will do the exact opposite.

However, when I wrote blogged last month there was one thing about “My” class extensions I did not know. Joe Binder, the program manager at Microsoft for the “My” classes whom I video interviewed several months ago, was gracious enough to provide a detailed comment regarding my post explaining that thing I did not know, and I quote:

With regard to conflicting names, it is important to note that My extensions must be added manually to each project; they will not show up by simply referencing an assembly. (My is actually a namespace nested under the root namespace of the project.) This point is especially compelling from the perspective of third-parties looking to extend My and the scenario you describe above: In order for any name conflicts to occur, users must not only reference the third-party assembly, but manually add the My extension to their project. If there is a name conflict, the user can back out the My extension and still use the third-party component living in the referenced .dll directly; or they can rename the My extension. The point is that all My extensions exist as source in the project; they cannot be pre-compiled.

Whew! That calms my fears greatly! It means .NET components with conflicting “My” extensions, especially from 3rd parties, will still be able to be used together albeit in reduced usability form.

However, Joe’s comment still doesn’t address the biggest reason I felt “My” class extensions will create a problem. If not somehow constrained, I believe the thousands of competiting and incompatible “My” class extensions will effectively shackle Microsoft and keep them from evolving the “My” class “standard” in future versions of VB for fear of breaking too many people working code. If I’m right, that will be a huge loss.

Let’s hope I’m wrong.