My namespace: Friend or Foe?

M

mskeel

Senior Contributor
Joined
Oct 30, 2003
Messages
913
For a while it seemed that VB.Net and C# were converging on a common framework -- that the syntax would be the only thing that separated the two languages what with operator overloading and XML comments (among others) in VB.Net 2005 and better inline compilation etc.. in C#. My opinion is that converging the languages is a good thing so that they are easier to maintain together. Then you're coding in .Net and not VB or C# so much. Each still has strengths and weaknesses that the other picks up slack on and vice versa.

And then I found this 'My' namespace in .Net 2.0 that is a VB only thing. It seems to once again diverge the languages pretty radically back to the same gulf that was VB6 functionality vs .Net when VB.Net first came out (msgbox vs MessageBox.Show). While 'My' namespace appears to add a lot of power, what is really going on behind the scenes here? Is a convergence of C# and VB.Net really that bad of an idea? How does mono play with this 'My' namespace or is it yet another way to make VB a Microsoft Proprietary language? It really seems like the 'My' namespace is like slapping on another proprietary API/framework/toolkit to the .Net framework...another dependency and divergence from the core .Net API. Or is the concept of ".Net Programming" flawed?

Any thoughts, opinions, or answers? Quite, frankly, it feels wrong. But at the same time, I don't think there is any way around it.
 
First, let me say that I am strongly of the opinion that the growing divergence of the languages is more a form of regression than progression, contrary to the spirit of .Net, and I am not fond of the "My" keyword at all, specifically because it makes VB code incompatible with C# code.

"My" is a compile time feature that uses standard functions from the standard .Net library. Any VB 8 compiler should properly compile code using the My keyword, and any .Net 2.0 library (Microsoft's, Mono, etc.) should implement the helper functions that "My" compiles down to (but in my opinion, usage of the "My" keyword should compile down to common .Net functions, not VB specific functions). Any proper implementation of .Net should fully support "My" at both compile and run time. It is just more work for the Mono team.

Maybe I'm crazy, but why didn't the VB team just develop a static My class in the System namespace so that it would be fully available for all languages. Well, if worse comes to worse, there are a few third party implementations of a My class that offer all the same functionality of the VB "My" keyword.
 
I agree with marble, that anything to make the logic of programming the .NET Framework similar between languages is good. So that only syntax needs to be changed when converting between languages.

I also think it would've been a neat idea to make the My namespace part of system.
 
marble_eater said:
Well, if worse comes to worse, there are a few third party implementations of a My class that offer all the same functionality of the VB "My" keyword.
Click to expand...
Are these available for C#? Got some links/recomendations?
 
I find it annoying that they bring the languages closer together (VB now gets operator overloading and the using statement), but then go and make them differ in other ways.

I really don't see the point of the My namespace as all the functionality offered by it is available elsewhere in the framework anyway...
 
This is only me guessing, but I don't think that operator overloading and "using" are there for language unification, but rather simply because they are nice features, regardless of what other languages have them. "using" has also been added to C++ (in terms of disposable objects). I'm guessing that it was a marketing ploy on Microsoft's part to leave operator overloading out of VB7 to give us another reason to upgrade to VB8 (and included in C# to give it a kick start). You have to remember that Visual Studio is as much about making Microsoft money as it is about programming.

The My namespace is there for one reason only, albeit a good one: convenience. It has become very typical of Microsoft to essentially provide VB aliases for already existing .Net functionality, either for the sake of Legacy VB programmers making the transition, or for users who don't know how to search MSDN for the class they need. (Don't take that personally, VB users.)
 
marble_eater said:
It has become very typical of Microsoft to essentially provide VB aliases for already existing .Net functionality, either for the sake of Legacy VB programmers making the transition, or for users who don't know how to search MSDN for the class they need.
Click to expand...
Sad, but true in my opinion. As I recall VB has always sort of been marketed as a language for learners, as being "easy", so I suppose it makes sense. Although, the retention of a lot of the legacy stuff was about decreasing the learning curve and removing barriers to entry (successfully I might add) for VB6 programmers, not really making things easier for folks. At least they are just aliases and everything is internally consistent (I hope :) ).

After the initial learning curve, My namespace probably will make writing code faster for VB developers, which I think was the point. And that is a good thing -- code reuse is a glorious thing.
 
Actually, the VB6 "aliases" are basically wrappers for .Net functions. You code calls MsgBox which in turn calls MessageBox.Show for you. The VB6 wrapper functions also perform safety checks, though (like checking if a reference is null before trying to call a function on it) for consistent behavior with VB6. I personally wouldn't ever knowingly pass a null reference to IsArray, for example, and if I did pass a null reference, I would like an exception to let me know, but instead it simply returns false.

The reason for these functions, really, though (and I know I am contracting myself), isn't so much about the learning curve but for the sake of code compatibility, which is actually a good reason to have them. I just think that they all belong in the compatibility namespace, and to hell with programmer compatability (I know that this does not make much business sense, but I am a hobbyist programmer, not a business programmer).

As far as "My," I do believe that some of the functions are inlined, but there are namespaces in Microsoft.VisualBasic.dll that perform services related to "My." Check it out with reflector. And in my opinion, actually creating a My namespace with real classes, which could achieve the same exact effect while also being available to all languages, would make much more sense. Why make it VB specific? I say it is a good idea executed horribly.
 
Last edited:
Back
Top