Nearly a year has passed since Microsoft announced .NET. At the time, few realized the dramatic impact that the highly touted .NET Common Language Runtime (CLR) would have on some of the existing and most popular development tools. Until then, a large part of the developer community was eagerly awaiting the forthcoming Visual Studio 7.0, specifically the incorporated Visual C++ 7.0 and Visual Basic (VB) 7.0.
VB 7.0 was going to be the perfect answer to C++. Microsoft touted VB 7.0 as capable of providing true object-oriented functionality, including real inheritance and full poymorphism. Many expected that the language's cutting-edge support for free threading would boost applications. VB 7.0 would have a powerful mechanism for exception handling, more effective debugging tools, and even a garbage collector for clearing out unused objects.
It never occurred to anyone that the new version of VB might not be completely backward compatible. If, as most assumed, VB 7.0 was to succeed VB 6.0, why would anyone need to entertain such nonsensical possibilities? However, doubts set in as the VB community began to realize the role of the CLR and the platform's language neutrality. As VB programmers opened the first Visual Studio 7.0 beta—which Microsoft promptly christened with the ubiquitous .NET suffix—they were shocked. It wasn't that the new UI was a surprise; what raised eyebrows was the extraordinary fact that when opening a VB 6.0 project, the new tool launched a conversion wizard instead of creating a new workspace!
Language Differences
The VB-to-VB.NET conversion wizard indicates a number of potential errors in your otherwise perfectly working code. Yes, VB.NET is all but backward compatible. Microsoft has dropped a vast number of little things and has added a relatively small number of big features. All these changes, though, pertain to the full integration of the VB development platform in the all-encompassing .NET system platform.
The CLR is the common engine that fuels all the languages that .NET supports. All the .NET language features are just features of the intermediate language that CLR understands. VB 7.0—or better yet, VB.NET—has free threading, inheritance, full polymorphism, garbage collection, and more. All these features, though, simply mirror the CLR functionality.
Because of this integration, VB has lost its identity and its backward compatibility. VB, as we know it in its VB 6.0 rendition, is dead; its replacement is a new language with a significant syntax likeness. VB.NET is just another OOP language that only looks like VB. If we want an inspiring model for VB.NET, we should look to VBScript 5.0 instead of VB 6.0.
Key Changes in VB.NET
VB.NET's key features include classes, exception handling, and a certain syntax rigor necessary to clean up and rationalize the language. The most important feature, though, is VB.NET's class structure.
VB has supported classes for some time. However, as of version 6.0, a VB class is simply an automation COM object that you write and invoke with an OOP-like syntax. COM doesn’t support inheritance, which, with polymorphism and encapsulation, is one of the foundations of OOP. COM only simulates inheritance by aggregating two objects. As a result, VB classes can only inherit at the interface level, not at the implementation level. In other words, with VB 6.0, you can write a class and make it inherit from a COM interface (using the Implements keyword). The actual VB syntax lets you express that inheritance in terms of classes, which falsely implies that you're using objects. Instead, you're only creating a component class (aka a co-class) for a COM object, which implements the specified interface.
In an OOP language, a class is a data structure with private and public members, with constructors and destructors. The class can derive from another class and can expose methods that a derived class could, in turn, override. Nothing of the kind is possible in VB 6.0 because VB classes are ultimately COM objects. When you derive a class from another one in a true OOP language, the compiler is responsible for resolving the calls to the variables of that type at compile time.
Given this quantum leap, it should come as no surprise to learn that VB.NET no longer supports Class_Initialize and Class_Terminate, which are just two technicalities that emulate constructors and destructors in the fake object-oriented world of VB 6.0. In VB.NET, real constructors and destructors are first-class citizens and, as a pleasant side-effect, you can declare and initialize an object instance on the same line.
Modern applications trap errors using exception-handling mechanisms based on the try/catch/finally logical construct. Basically, the try block wraps the code you consider harmful to ensure a procedure's stability. If an error occurs, control automatically passes to the code in the catch block. Whatever happens, the application continues with the code that the final block contains.
With this new syntax element, the various On Error Goto and GoSub disappear. Looking at VB.NET's type model, the first thing that comes to mind is the lack of Variants, which, in VB 6.0, is the generic data type that you use when you can't use a more specific type or when you need common data. In VB.NET, you have the Object type instead.
Is VB Dead?
Many have complained about the changes Microsoft implemented in moving from VB 6.0 to VB.NET. However, most (if not all) of these changes result from a radical change in the language's layout. VB.NET is simply a new OOP language with a syntax that deliberately mimics the VB 6.0 syntax. VB 6.0 and VB.NET are two different languages, and the differences are particularly evident where they look similar. Both languages have classes, but these classes are where the two languages are most distant.
