Archive

Posts Tagged ‘VB6’

Why Microsoft.VisualBasic should be buried

December 6, 2011 Leave a comment

A friend of mine, who I hope won’t object to me recounting this anecdote, was recently posed the following interview question:

What would you change about the .NET framework?

To me, the answer was simple: I would deprecate the Microsoft.VisualBasic namespace with immediate effect, and phase it out entirely by the time version 5 of the framework was rolled out. It is a relic of a language that ceased to be ‘current’ 10 years ago, yet is still being actively used; even this week I have seen code, recently written to run under .net 3.5, actively using methods from it.

To understand the reason for it existing, it is worthwhile looking back to when .net was introduced. Microsoft was targetting two separate groups of developers: those coding in C or C++, for whom it developed C#, and those moving forward from Visual Basic 6. For this latter group, they included a number of VB6 commands, using them as wrappers around the .net equivalents; these were placed within the Microsoft.VisualBasic namespace, with it being automatically included as a referenced namespace in all new VB.net projects. As Microsoft go on to say in their page about Visual Basic .NET internals,

An important goal for Visual Basic .NET was to retain as much backward compatibility as possible, while providing more power and flexibility for the developer. This was accomplished by providing “helper” methods such as Rnd (which is a static method on an imported class) and intrinsic language features, such as CInt, to provide functionality identical to that of Visual Basic 6.

Unfortunately, not all VB6 developers embraced the object models available, and as a result far too many developers are still using the constructs such as CInt() as shortcuts to the .net equivalents. Those developers presumably assume that CInt(number) is equivalent to int32.parse(number) both in functionality. Nothing can be further from the truth; from the same page:

While there are a few specific methods that don’t provide the same performance characteristics as Visual Basic 6, you can fully expect that a Visual Basic .NET application will significantly outperform its Visual Basic 6 counterpart.

Our simple CInt() function performs a wide variety of options, covering parsing, boundary checking and rounding. Using it leads to inefficient code and, more importantly in my mind, developers who are unskilled in the wider concepts of OO within the framework.

Microsoft.VisualBasic is a relic, and deserves to be buried.

Advertisements