We want you to pay special attention to one primary feature of this library: It's documentation! It was our chief desire to provide you all with a library that is useful, reusable, and quickly LEARNABLE!
Recently, I came upon a need for a multidimensional array. I immediately turned to Google to see if I could locate something already designed, coded, and tested. To my dismay, I found only a smattering of hints, discussions, and some skeletal code (e.g.
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.
Our two very fine Eiffel engineers have been great mentors. The staff of Eiffel Software have also been excellent mentors and helps. The names are numerous so I won't list them. From them we have and are learning a great deal.
At the present time, each new day of working with Eiffel shows me both how far I have come and how much further remains to go. A faithful saying is: "Whatever you focus on expands." Working with Eiffel is no exception to this rule.
We are learning and have learned a great deal in the last two and half months of working with our two very fine engineers.
No matter what language used, software is concerned with the states of objects and transitions between them. Within the Visual FoxPro paradigm, I saw the notion of a State Machine as a fantastic solution to a common problem: How do I make my interfaces respond appropriately to user interaction?
The previous example compared getting similar data from a Visual FoxPro database container loaded and ready for presentation with the same task in Eiffel. The next step is to take the prepared data and present it to the user. The caution for both FoxPro and for Eiffel is this -- In production code you most likely won't do things this way.
The heart and soul of Visual FoxPro is a decent database engine coupled with a capable attempt at an Object Oriented language. Any FoxPro engineer will quickly point out this marriage as a key strength of FoxPro. It has been a tremendous selling point that I have used personally with clients again and again over the last twenty years.
I have been working with FoxPro in nearly all its forms since May of 1991, starting with FoxPro for DOS 1. Thankfully, I was able to graduate to each new version as they were released. A resemblance of Object Oriented software engineering appeared in VFP 3.0 in the mid-1990s. I was immediately stumped by it.
I have been both a W-2 employee and a free-lance contract software engineer. My contracting days lasted about 10 years (more or less). During that time, I began to see a reality happening for me repeatedly.