Eiffel for Visual FoxPro Programmers: Visual Limits

A FoxPro colleague shared a factoid about FoxPro that I had not connected the dots about. In FoxPro most class primitives are visual. Text-boxes, combo-boxes, check-boxes, edit-boxes, buttons, pictures, containers and so on are all manipulated from the visual aspect. What this means is this: When you want to make changes to a class, FoxPro opens the class visually and then allows you to change the class properties and code. To accomplish this feat, FoxPro creates an actual instance or object in memory of the class.

Once the instance of the class is in memory as an object, the programmer has access to the properties, events and methods of the control. While there is a way to work with controls without creating visual instances of them, the means for doing so is NOT the prescribed method, nor is it the commonly used method. About 99% of FoxPro programmers choose to start visually and code from there.

The limitation begins with the visual-instancing method. Pretend we have a visual text-box base class with a descendent child. We want to manipulate code in both the parent (ancestor) and child (descendent) at the same time. Moreover, the changes we want to effect have nothing to do with the visual appearance of the text-box, only the business operation of them. Ready for the limitation? In Visual FoxPro doing this simultaneous manipulation of text-box code in two related classes in not possible! What happens?

With either the parent (ancestor) or child (descendent) class instance living in memory, FoxPro cannot load the complement. For example: If you start with the ancestor, you cannot then load the descendent. The reciprocal is true as well. This forces the programmer to open one, make changes, close it -- then -- open the other, make changes, close it. This cycle continues endlessly! Opening, changing, closing, opening, changing, closing -- and because of what? Simply the fact that the visual instance of the class limits the scope of what can be open to a single class at a time.

This is the visual instance created by FoxPro when a class is open for editing.

This is what happens when you attempt to open and manipulate changes on a related class.

How is Eiffel different?

First, everything in Eiffel is code text. There is no visual instance created in memory. Doing so at design-time may be impossible and is (at the very least) difficult. Moreover, even if the control was to be presented visually, to what purpose would you want it that way each time? This is especially true when we consider how most of the changes we make are either not visual, but behavioral -- or -- the changes we make to visual aspects of our controls are complex and dependent on the interplay of code existing across the inheritance tree. Finally, the visual behaviors of the visual aspects of our software is highly dependent on the data. Modelling these behaviors in the static world of design-time is simply not possible. The best place to handle this task is where it matters most -- the run-time testing and use of the software!

This last point is especially important when multiple inheritance is taken into account.

Working solely with text and forcing the visual aspect to the run-time frees us (as programmers) to place our engineering focus where it belongs: on the code.

Our team has spent the last two weeks building a very complex and powerful GUI tier class framework. What is enormously powerful and interesting is how we're nearing completion of this and we have yet to see what the class code looks like when it is rendered on the screen. Yes -- that is correct; you read it right. We have NOT seen our work visually displayed! Not even once!

I will let you know how it turns out, but here is what I expect: When we do finally get to see the visual results of our work, there will be some tweaking of the layout, positioning, coloring, sizing and so on. This is to be expected. However, what will be true is how this will amount to about 10% of the work, where the first (and more important work) job of behavior will have already been handled. The framework, architecture, logic and organization work will have not only been completed, but thoroughly tested, vetted and proven. All of this has happened WITHOUT the need to "see" the controls!

Again -- I'll let you know closer to the end what the fullness of the result is, but I suspect we'll find the code-quality to be very high and the payoff will be a GUI that is rock solid stable, predictable and easier to work with in code -- which -- for a programmer is goal is it not? Oh yes -- and lest we forget the end-user: We expect the end-user will get the value of a GUI that is high quality, does what they want, doesn't crash and just plain works.

Final thought: Can you do this in FoxPro? Sure you can. Just work with single classes in single PRG files instead of working visually. You'd start heading down the same trail, but you'd do so without the benefits of what Eiffel brings to the table. Nevertheless -- you could. Still, you'd be going against the grain of about 99% of how FoxPro programmers not only work, but how they are trained to work. Moreover -- FoxPro is not the only platform where this is true. The .NET folks get trained like this too. Visual Studio works this way. When you create a form, you get to see the form visually before you ever touch the code. Can you say, "Same dance, different partner?"

Ciao Ya'll!