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.

It has been a month since my last blog entry because I could not recall precisely where the blog was!

I am pleased to announce a new Eiffel tool that is able to convert (or wrap) Objective-C frameworks to Eiffel.

I've been working on this during my master thesis at Eiffel Software and, although not completely ready for development in the software industry (there are still several manual settings/details that might be improved), we're going to release a public beta soon.

From time to time, I will do my best to keep this blog and it associated community up-to-speed on the development of the Jinny Logistical Order Fulfillment Technologies (JLOFT) project. The JLOFT system has been conceived as an end-to-end general business application. The application is being designed to manage a specific wholesale order fulfillment system (e.g.

In Eiffel all arguments of routines are pure input arguments. There is no possibility to return an argument. The only possibility is to write a function and return a value as "Result".

Furthermore Eiffel has command query separation, i.e. a command can change states and a query should only return a result and do nothing beside that.

Hello everybody.

The following is a short description of a solution to the catcall problem (recently posted in comp.lang.eiffel as well):

In Eiffel it is easy to generate runtime type errors. Therefore Eiffel cannot (yet) be considered to be a typesafe language.