In Vb.NET we can use the Imports statement to create aliases, such as :
Imports VB = Microsoft.VisualBasic
Then in code we can simply type VB. And intellisense lists the members of the Microsoft.VisualBasic namespace. Pretty cool huh ?
But what would be way cooler is if we could use the . syntax in the alias, and that member/type resolution promoted the Imports Alias over any other namespaces.
For example, let’s consider the case where you have code such as :
Dim x as New Foo.Bar
Let’s assume the Type Foo.Bar is in an assembly that your project has to reference. Now if for one reason or another you need to version that, it would be nice to be able to alias a similar class. In this case, say I create a class that inherits from Foo.Bar, and name it Zzz.Bar2 . Sure I could refactor all the code, but wouldn’t it be nicer to write :
Imports Foo.Bar = Zzz.Bar2
Now all code that pointed to Foo.Bar will be pointing at Zzz.Bar
Finally, the last addition I would like to see, would be the ability to specify the assembly as well, eg:
Imports Foo.Bar = Zzz.Bar2@myassembly.dll,18.104.22.168
where you could also specify the assembly version as well.
Personally I think this would give the developer ultimate control when it comes down to versioning issues.
Oh, and as a side note, regardless of what some people may say, DO NOT extend the My namespace until such time as VB gets versioning syntax like this. You wouldn’t use the root System namespace, or the Microsoft namespace, so don’t use the My namespace unless Microsoft either gives you an iron clad written guarantee they won’t introduce types with the same name in the My namespace (1) or they provide you with language constructs that allow you to easily fix the problems caused when they do.
(1) if your namespace is uniquely identified within My using your company name or similar, then it really doesn’t belong inside the My namespace in the first place. That would be like putting Acme.Widgets inside the Microsoft namespace. Wrong, wrong wrong, DON’T DO IT !!!