Why Break Compatibility?

Why Break Compatibility?

Why did Microsoft redesign and restructure the language? Why couldn t it add these new features and still keep compatibility with Visual Basic 6? There are several reasons for this, as we discuss in the sections that follow.

Adding New Features

Some of the new features in Visual Basic .NET could not have been added without a redesign. Adding visual inheritance and accessibility support to the forms package required redesigning the forms object model. Adding Interface statements and attributes to the language made the language more powerful by enabling a greater degree of fine-tuning but required changing the language and file formats. Fixing DLL hell meant that versioning and deployment had to be redesigned.

By far the biggest reason for the changes, however, was the need to integrate Visual Basic with the .NET platform. Cross-language inheritance, debugging, and unfettered access to the underlying APIs required the standardization of data types across languages, which meant changing arrays to be zero based and removing fixed-length strings from the language. Redesigning the Web and data access classes to be more scalable meant even more changes from Visual Basic 6.

Fixing the Language

Visual Basic has grown over time, and as the language has been extended, some areas have become inconsistent and problematic. A good example of such an area is default properties. The rules for when an assignment is to be a default property and when it is to be an object have become inconsistent. Consider the following Visual Basic 6 example, where Form1 is a form in the current project:

Dim v As Variant v = Form1

This code causes an error because Visual Basic 6 tries to assign the default property of the form (the controls collection) to the variable v. Contrast this behavior with the following Visual Basic 6 code:

Dim v As Variant Set v = Form1

In this example, v is assigned the value Form1. In both examples, the right side of the expression is exactly the same, yet the value changes depending on the context. To anyone who didn t write the code, it s unclear from looking at the code what is being assigned: the object or the default property of the object. In Visual Basic .NET, parameterless default properties are not supported and must be resolved.

Another example of an inconsistent feature is the New statement. Consider the following Visual Basic 6 code:

Dim c1 As New Class1 Dim c2 As Class1: Set c2 = New Class1

At first glance, the two lines seem to do exactly the same thing. Both c1 and c2 are being set to new instances of Class1. Yet the two lines have quite different behavior. The statement

Dim c1 As New Class1

means that the variable will be re-created if it is set to Nothing and subsequently reused, whereas the effect of

Dim c2 As Class1: Set c2 = New Class1

is that c2 is created once. If c2 is set to Nothing, it will not be re-created automatically if it is referenced again. This subtle difference in behavior can lead to hard-to-find bugs. In Visual Basic .NET, both statements cause one instance of the class to be created. If the class is destroyed, it is not automatically re-created if it is referenced again.

Modernizing the Language

Another reason for breaking compatibility is to modernize the language. For example, the meaning of Long is now 64 bits, Integer is 32 bits, and the keyword Type has been changed to Structure. Some of these changes we can probably attribute to the floodgate effect. Once Microsoft opened the floodgates to new features and changes to fix the language, it became more acceptable to make other changes that were not quite as critical.