2.9 Features you might miss in Visual FoxPro

Features you might miss in Visual FoxPro

Visual FoxPro has a powerful object model. However, other object-oriented languages support a couple of things that Visual FoxPro doesn't. With every new version of Visual FoxPro, we get a little bit closer to having full support for all object-oriented concepts. Visual FoxPro 6.0 has only a couple of little things missing, and most of them keep even the experts arguing whether or not they belong in a truly object-oriented system.

Multiple inheritance revisited

I talked in brief about multiple inheritance, which means that one class inherits from two or more parent classes. Visual C++ allows you to use this feature.

Multiple inheritance introduces a whole set of new possibilities. Let's re-examine the Movie Theater Complex example I used in Chapter 1. I talked about buying other theaters and creating classes for these new theaters that link in the existing set of classes. To do so, I simply created a new subclass of the existing screen classes and added all the methods and properties the screen classes had. However, this might not be the perfect solution, because changes in the theater class would not automatically be inherited in this class.

Using multiple inheritance, I could simply create a new class that inherits from the foreign screen class as well as from my screen class. This way, it would automatically inherit the interface and the original behavior. Unfortunately, this perfect-looking scenario introduces a couple of serious problems. What if both parent classes have methods or properties with the same name? How is FoxPro supposed to know what the parent class is when a DoDefault() is executed?

C++ programmers will assure you that there are perfect solutions for all these problems, and I don't doubt it, but it's obvious that these constructions can end up as a maintenance nightmare. I personally would like to see multiple inheritance in Visual FoxPro, mostly to resolve implementation issues. However, I realize that not having multiple inheritance is not a show-stopper, and that it would introduce problems that would make Visual FoxPro almost impossible to use, especially for beginning and intermediate programmers.

Friendship relations

There are four different method and property visibilities in an OOP language: public, protected, hidden, and friend. I've discussed the first three. Friend is very similar to protected, but it allows you to define that certain classes are friends of others and therefore can see all the protected properties.

This is very useful in complex object systems and in composition scenarios. Without friend relations, you'd often end up making properties or methods available to all objects, just because one other class (possibly a container class that hosts the current object) needs access. This often turns a clean design into a badly polluted implementation.

If I could choose one missing feature to be implemented in Visual FoxPro, it would definitely be friend relations.

Static properties

Static properties are shared among objects. This, again, is a technique that's popular in C++. You could define a property as static, instantiate an infinite number of objects of this class, and refer to this property. No matter from which object you talk to this property, you would always talk to the same property. This could be used to count instances, or to save memory by allocating memory for properties that don't change. This is a great feature for a low-level language like C++ that does a lot of things in a hybrid fashion, rather than in a truly object-oriented way. However, it breaks all the rules of encapsulation. Sometimes it seems that Visual FoxPro's object model is cleaner than the C++ model.

Operator overloading

Overloading operators means that a standard operator like "+" behaves differently than it was initially intended. Certain operators like "+" behave in a well-defined way in Visual FoxPro. If the operator is used with two numeric values, they are added to each other. When this operator is used with strings, they are concatenated. However, there is no associated behavior for this operator when it's used with two objects. This makes sense because there couldn't be a standard way to add an object to another one. The same applies for other variable types.

However, it might make sense to sum up objects of a certain type. If there are two invoicing objects, we could calculate a grand total by simply adding one object to the other. At the same time we calculate the total tax amount, we could come up with a new number of items in stock (by subtracting the ones we sold in that invoice) and so forth. Obviously, FoxPro couldn't know how to do all of this. With operator overloading, we could customize the behavior of the "+" operator (this works with all kinds of operators) for specific items.

This is not an object-oriented feature at all because it works with other items and variable types as well, but it seems to go along great with objects. You could specify how objects are added or subtracted from each other.

This would be a truly great feature to have, but again, it's not object-oriented and there must be better ways to accomplish the same goal in truly object-oriented ways. You could provide methods that do just the same as the operators would. In addition, I don't see a way to implement something like that in Visual FoxPro because C++ compiles its programs in a very different manner from Visual FoxPro.

Copying objects

In Visual FoxPro, there is no way to create an exact copy or clone of an object at runtime. There is no question that this might be handy in a number of scenarios. Well, maybe in Visual FoxPro 2000.

Note that the Visual FoxPro documentation lists a function to clone objects. However, this does not work at runtime. It is useful only when creating builders to automate processes while creating forms or classes.