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.
4 Replies to “Just Say NO to Extending the “My” Classes in VB 2005, Redux”
(I know this is the wrong place to mention this). It would be nice if "My" namespace extensions all ended up in a standard place; for instance "My.Extensions" (dot whatever). If each vendor (or Microsoft forced each vendor’s extensions to) use an alternate location that specified an extension. Then Microsoft could sometime down the road add Zip to the My namespace without blowing up any third party extensions that have already been written.
Just my 2 cents….
> My is actually a namespace nested under the root namespace of the project
So, why is this any different than any other collision because someone added to a namespace in the future?
I’ve been meaning to blog about the more general case of namespace collisions, and you inspired me to get it written (http://gendotnet.com/blog/archive/2004/09/17/261.aspx).
Perhaps I’m missing something in why the My namespace presents more serious problems than the general case of future namespace collisions.
>> in a standard place; for instance "My.Extensions" (dot whatever).
>> So, why is this any different than any other collision because someone added to a namespace in the future?
GREAT question. Let me answer by analogy. Let’s say you were born outside the USA and are given immigrant status by the US goverment. Where you gonna enter? Ellis Island. Where are you likely to settle? New York City. You *could* settle in any of the 50 states, 3000+ miles away, but chances are you are going to settle within 25 miles of Ellis Island in NYC because that’s where you are when you enter (well at least that’s often the way it has happened in the past.)
So… all other namespace collisions occur at somewhat random locations. Microsoft is inadvertently leading developers (like lemmings) to one single namespace where all those namespace collisions will occur. Talk about a traffic jam! (as I mix my metaphors. :)