by Jim Karabatsos - GUI Computing
First, let me be quite clear about my reaction to VB5 - I LOVE IT.
VB5 lets me do the kind of programming that I really like to do, creating small, re-useable objects that encapsulate complex functionality. I do not want to get into the argument about whether VB5 is a "true" object-oriented language and whether inheritance is absolutely necessary - I'll come back to inheritance a little bit later.
What I do want to do is to play devil's advocate for a while, to forget about how excited I am about the new features and come back to what I think are some very important problems with the language and development tool. It's not that I want to bag Microsoft or Visual Basic - I actually have a lot of time for both of these entities - it's just that there are some things that really need highlighting. So here goes…
There are several things that I think need to be fixed with Visual Basic. The first of these is Evil Type Coercion, or ETC for short.
In VB (starting from Version 4), the following code will compile and execute with no errors:
Option Explicit Dim I As Integer For I = 1 to "5" Print I * "10" Next I
Now am I the only person who thinks that this is really scary? What the heck is going on here? I said Option Explicit and I really meant it! Why are all the strings being processed as numbers?
What is going on is ETC. The various variables and constants are being converted as necessary to make the statements work. Now this is a good thing if you are working with cells in an Excel spreadsheet; after all, what data type is a cell's contents anyway? But I'm not writing an Excel macro - I'm developing complex code and I do NOT want the compiler to mask my errors by these shenanigans. If I write something like this:
Dim I as Integer I = I + "1"then the chances are I have made a mistake and I would expect the compiler to pick that up. If I want to do a type coercion then I will code it explicitly.
What MS should do in VB 6 is to introduce an Option StrictAndIReallyMeanIt (a.k.a. Option Anal) that disables ETC. This would not break old code but would let me write new code the way I think it should be. Personally, I would enable it in all my existing code too; I shudder to think what latent bugs it would bring to light.
If you agree, send email to Microsoft's VB Wish List telling them that you want an Option StrictAndIReallyMeanIt. If you don't agree, then please keep quiet!
The other thing that needs to be fixed in VB6 is UniMess. We really need explicit control of Unicode/Ansi conversion. The current situation works OK most of the time but is a time bomb for anyone with old (pre-VB4) code that stores binary data in strings. The fact that MS saw fit to change an existing data type in such a fundamental manner worries me a lot - it is not the attitude I would be looking for to demonstrate a commitment to the longevity of our code base. It seems bizarre that MS did not change an Integer to 32 bits but saw nothing wrong in changing strings from 8-bit to 16-bit characters.
Let's not forget the Type Unalignment problem. Starting in VB4, UDTs have their members aligned on "natural" boundaries. Fixed-length strings are aligned on byte boundaries (in Ansi !!!), integers and booleans on even addresses and pretty much everything else on a 4-byte boundary. This might well be efficient and the way it is generally done, but it does cause us some problems with some third-party DLLs that do not pack structures this way. Even some MS APIs don't conform to this convention. I don't really have a problem with this alignment option being the default for VB but I do want some way to override it. I think syntax like this would work without breaking existing code:
Type MyType Packed . . . End Type
As for inheritance, let me first state that I want it. Let me also state that it is not something most developers will miss. Inheritance serves two important functions in an OOP language: it provides for easy extensibility and it provides polymorphism. In VB5, these functions are serviced differently. Polymorphism is provided for by the use of Interfaces. Two object types are can be treated polymorphically if they implement the same interface, at least as far as that interface is concerned. This is actually quite neat and is not unlike the interface facilities in Java.
Where the lack of inheritance causes more stress is in the extension of existing objects. With inheritance, you have an ancestor object type that provides an actual implementation of some of the smarts of your object; all you need to do is to write what is different about your new, descendent object type. This makes it easy to create object hierarchies, starting with generic classes and evolving ever more specialised descendants.
With VB, however, you can only extend a class by encapsulating it. In a nutshell, this involves instantiating an instance of the type of object you want to extend from, and then creating a whole host of properties and methods that are really nothing more than conduits to those of the encapsulated object. Then you can add or modify some of these to implement the new behaviour and capabilities. If you implement all the interfaces of the contained object, you are even polymorphic with it.
If this sounds messy, it is. However, the wizards in VB5 make that quite straightforward. Sure, a whole lot of plumbing code is generated, but who cares as long as you don't have to write it?
The reality is that for developing applications, inheritance is not likely to be missed. There are quite good arguments that inheritance tends to weaken encapsulation and I think that the latter is far more important in application development. However, if you want to develop application frameworks (something that I want to do) or a lot of controls, you will constantly find yourself doing a lot of work to make up for the lack of inheritance in the language.
I would love to see inheritance in VB6 (after all, nobody would be forced to use it), but I am not holding my breath. I don't really believe that MS sees Visual Basic as a development environment for serious developers - after all, serious developers use C++.
Can you imagine the following scenario?
Microsoft announces new useability features for VC 6.
Finally, Visual C++ developers can benefit from the advanced language features that have helped Visual Basic programmers for years.
The next version of VC++ will have automatic parameter coercion. When you prototype a function, the compiler will note the required type for each parameter. When that function is later invoked, the compiler will automatically convert all parameters to the required type (by converting to and from the CVariant type). This frees C++ programmers from having to keep track of data types and will make them more productive.
Another timesaving feature in VC 6 is the enforcement of natural alignment in structs. While this has long been the default for Win32 builds, the new version will not allow any other type of alignment in structs. All compiler switches and pragmas relating to structure alignment have been disabled. "Why would any programmer want any other type of alignment?" asked a senior technical evangelist.
Also introduced is Auto-Unicode. All strings are now automatically Unicode strings. This should be transparent to most developers, as strings will be translated automatically to and from Ansi whenever a DLL function is called. Why mess with conversion APIs when the language can do it all for you?
OK, I am being silly here, but these are EXACTLY the changes that MS has made to VB. If these changes had in fact been made to VC, developers would have been up in arms. It is totally unacceptable to make these sorts of changes to a language.
Of course, Visual Basic is different. It is obvious (to me, anyway) that since Version 4, MS sees VB primarily as the embedded macro language in Office and third party products. Whenever the needs of professional developers conflict with the needs of macro developers, the macro developers will win out every time. They certainly have done so in the last two versions.
Yet despite all this, I do like Visual Basic 5.
Really I do.