This post originated from an RSS feed registered with .NET Buzz
by Paul Vick.
Original Post: The My namespace and C#
Feed Title: Panopticon Central
Feed URL: /error.aspx?aspxerrorpath=/rss.aspx
Feed Description: a blog on Visual Basic, .NET and other stuff
Don and Robert ask in comments to my previous entry, “Will C# be able to use the My namespace?” The answer is: yes and no.
Most of the functionality contained in My is implemented by types that will be defined in Microsoft.VisualBasic.DLL. So C# users are welcome to reference the DLL and use types such as System.IO.FileSystem or Microsoft.VisualBasic.MyServices.MyComputer. Besides the cognitive dissonance of having to actually use the name “VisualBasic,” there's really no difficulty there.
However, the top level “glue” that brings all the My pieces together is something that's compiler-specific and so C# users won't see it. The top-level My stuff is compiler-specific for two reasons:
The My types exposed in a particular project are dependent on the type of the project. A web service project will have a different My namespace than a WinForms project will. Thus, the top-level definition of My has to be integrated into the actual building of the project.
Pieces of the My namespace (such as My.Forms) are dependent on objects that are actually a part of the project itself. Thus, the compiler has to specially generate those pieces of the My namespace at compile time.
Roy raises the question as to whether divergence between the languages like this is a good thing or a bad thing. While I'm sympathetic to his point about increased difficulties moving between two languages, it does raise the question: what's the point of having two separate languages if they have exactly the same set of features? Case insensitivity vs. case sensitvity, for example, is not reason enough alone for Microsoft to invest all the money that it does building both products.
Ultimately, feature set comparability has to be a balancing act between innovation and knowledge portability. If C# and VB cannot implement a new feature without the other language implementing it, the user ultimately suffers by way of reduced language innovation. It would be hard to argue that VB users should not get Edit and Continue back because C# doesn't plan to support it in Whidbey. Similarly, should C# users not get anonymous methods because VB doesn't plan to support them in Whidbey? Inevitably, the best ideas of one language will be cribbed by the other language. If My turns out to be a smashing success, I'd expect C# to come sniffing 'round it the next time around. Certainly we're watching how iterators and anonymous methods play out as we think about features for the future.
Innovation, however, does come at a cost and that can't be ignored. But I think, in the end, the cost is worth it to both languages' users.
Previous Topic
