VB should never blindly follow C#
Sat, Dec 18 2004 0:35
This is a ping back to Mitch’s ping back regarding my earlier entries on Aliasing in VB.
Mitch suggests that instead of using Imports, that VB.Net could take the same approach as C# has. Well let’s look at what C# does in a bit more detail…
For C#, using aliasing-versioning is a two (or three) step process.
First thing is you have to assign an alias to the assembly being referenced. This is not an issue if compiling by command line, but to use this from inside VS.NET, it will require the IDE to have modifications to allow you to set the alias for the assembly. This can be overcome, but it’s an extra requirement.
The next thing you have to do is indicate you are using that alias in your code by using the extern keyword, such as extern alias foo, where foo was defined in step one above. Okay so at this point we have the first level of duplication. We already defined the alias to the compiler with the /reference switch, but here we are stating that we will use it ? This step seems completely redundant and must be the fruit of command line compiler only mentality This duplication, is also two fold. Now there are two different aliasing constructs in the language, using, and extern alias.
And of course the final step is to actually use the types in your code. Here, C# makes the alias as a pseudo global, that is, rather than foo.sometype, you have to use foo::sometype. At this level we begin to run into some real design limitations. If you change the versionsing, which is actually a likely scenario as this type of versioning is usually a “Stop gap” or temporary measure, then you will need to change all the code as well.
Now, having looked at what C# does, and compare that to the syntax I suggested. First it means that no new keywords (such as extern and alias) need to be introduced. Next it means the IDE does not have to change the reference dialogs, and you can still simply compile from within VS.NET. It also removes that redundant step C# currently employs. Finally, it adds more flexibility in that you can update the code simply by changing the Imports statement. And the language has one aliasing construct. The Imports statement syntax would be simpler, more flexible, and in keeping with the language.
So should VB.NET blindly follow C#’s way of doing things ? I don’t think so.