I have had several messages back and forth with an I/T Architecture group at our national office. They are telling me that VFP does not support OOP - "it fakes it likes VB does". I have been arguing that VFP is a excellent product for sometime but I seem to be starting to drown and need a hand. I have cut and pasted the emails below for comments. Sorry it is so long but I think you need the full picture. These guys have a slight VB bias similar to our VFP bias.

I sent to them :

If your not the one to answer the following questions let me know and I'll keep looking for the right person. I have several Visual FoxPro Programmers that have significant experience using that product. What I'm wondering is can I continue to use this product to build COM Objects for use with IIS and MTS. I am aware the VB is the recommended tool but VFP 6.0 has numerous benefits including :

- OOP ( including inheritance ) ( Big + when developing components)
- Components run faster thanks to the data-centric language of VFP
- Strong ability to retrieve and manipulate data very quickly. A Visual Foxpro component that works with data and returns HTML will typically be very fast and very flexable.(much faster than VB)

If VFP 6.0 has been disregarded from the departments perspective does a document exist explaining why ?

I have just finished reading the "32-bit Development Platform Standards and Guidelines" and on page 27 there is a table listing recommended and discouraged tools. FoxPro is discouraged which makes sense, but I don't see Visual Foxpro 6.0 or Visual C++. I'm wondeing if this means the jury is still out or what?. On page 38 the migration for Foxpro from 16-bit to 32-bit is as follows :

"Use Visual FoxPro v3.0 to convert from 16-bit to 32-bit. Visual FoxPro 5.0 or 6.0 can then be used as the 32-bit development environment".

This would lead me to beleive that Visual FoxPro is acknowledged as a Tool within the department, but who knows. As you can tell I am quite confused with regards to the developements tools. (i.e. what's reccommended, what's standard, what's what's). The 32-bit doc did not have a contact name attached to it for further information.

Bill sent back to me :

The issue is just a question of support. We are attempting to organize our support teams to give good support to a small number of tools. There are a large number of tools that have not been specifically excluded from the support strategy, but rather the approach is to say what is supported--and not what is not supported. Hope that helps.

Regarding your points about VFP and OOP, I have a hard time believing that VFP supports Inheritance when COM itself only supports limited inheritance; that is, Interface inheritance, and not Implementation inheritance. And re-use is facilitated by Containment and Aggregation. As VB evolves, it seems to me, that more and more of the COM model is exposed in this product, and it is therefore a good choice for HRD. But I am not yet an expert in this area...so I'll copy this note to some of our experts and get their view too.

I sent back to bill :
I apprecite your comments. I'm certainly no expert in COM either at this stage of the game. I have been using a group of Expert VFP Developers at http://www.levelextreme.com for quite some time. This is a largest support forum for VFP and you can post problems and get answers. Most of these experts have a good VB background as well. They all seem to concur that overall VFP clearly outdoes VB at this time and version(6.0). The other piece of info comes from Microsoft's Q/A (MS wrote the questions and the answers) website at :

http://www.microsoft.com/catalog/display.asp?site=751&subid=22&pg=4 The seventh question asks point blank "Why would I build a component in Visual FoxPro when I can build the same component in Visual Basic, Visual C++, or Visual j++". The response :

"Visual Foxpro components are extremely fast, thanks to the data-centric language if Visual FoxPro and its ability to retreive and manipulate data very quickly. Further, Visual FoxPro can build strings very swiftly. A Visual FoxPro component that works with data and returns HTML will therefore typically very fast.

Visual FoxPro also has object-oriented programming capibilities, including inheritance. This provides a high degree of reuse across applications. A Visual FoxPro developer could create a set of classes that includes the core funtionally of a WEB database component. That code would not need to be rewritten each time a component was needed in a web application. The developer could merely create a component that inherits the base functionally and then add it to application-specific code.

Finally, building COM components in Visual FoxPro 6.0 is an excellent way to reuse existing code. Code that is already written and tested can be built into component, rather than being recreated in another language."

John sent back to Bill :

I agree with you on all points. Foxpro is also very poorly supported in comparison to VB, C++ and for that matter Java.

In terms of OOP, this is a rather naive statement. Foxpro supports OOP about as well as VB does in other words it is NOT an oop language. It fakes inheritance just like VB does. It is an interpreted language and you can make it look like it is doing all kinds of things that are just smoke and mirrors. It is built on COM, uses COM and is about as OOP as COM; no matter what the developer see.

The performance and data manipulation claims are again largely hot air. Foxpro and VB are roughly equal in terms of data manipulation. In terms of data access, they are once again roughly equal due to both tools using the same technologies to get at the data (ADO, ODBC, OLEDB). Foxpro is built upon the same pcode base as VB so I cannot see how it could possibly be much faster. For market share reasons VB gets significantly more development dollars from MS so it will always be ahead of Fox as far as a premier tool.

In terms of recommendations I would force VB over Fox. C++ is for specialized tools and developers who know what they are doing.

Stan sent back :

I agree with Tim's statement regarding support. If the groups wanting to use VFP can substantiate their requirements to do so to the ITSC and it adheres to the corporate strategy of HRDC then the support should come from Marc Levac's application group. There are a large number of products that are not "officially" supported.

Regarding Scott's comment on the VFP and OOP, I think this should be taken as an opinion only. I can find no evidence which supports or refutes the claims that VFP objects returning HTML are faster than ones defined in VB.

With this in mind see the statement below quoted from Mr. John V. Petersen, president, Main Line Software, Inc. in the January 2000 issue of FoxPro Advisor.

"In my opinion, the real differences between VB and VFP lie with COM. VB *is* COM. From an N-Tier standpoint, VB is far superior to VFP. In VB, not
only can you define your own events for Async processing. These events, with VFPCOM, can now be recognized in VFP. This is a BIG deal.
You have far better access to the Windows API (structures, pointers, call back functions, etc..) as well. You can define default properties,
MTS integration is better, multiple interface support, etc.... And, lets face it, ActiveX controls behave the way they are supposed to in VB.
These to me, are the big reasons why somebody would consider adding VB to their development platform toolbox".

Below is my preamble on Visual FoxPro.

Visual Foxpro is considered an object oriented language by the hardcore developers that utilize it.
It does provides programmable dynamic (run-time) subclassing, and data dictionary capabilities.
Microsoft Corporation released VisualFoxpro in September 1995, shortly after the introduction of Windows 95.
Similar to VisualBasic, Visual Foxpro (VFP) is a RAD tool that uses ActiveX visual components, and interoperates through OLE automation or by creating COM servers. VFP can also subclass ActiveX components and COM automation objects.

Visual Foxpro operates on dynamic inheritance. It instantiates classes from a library or from base classes. It can also modify and save classes - including contained objects into the class library at run time.

There are three major versions of Visual Foxpro: VFP 6.0 and VFP 5.0, (first released in September 1996) run exclusively on 32-bit Windows
operating systems. VFP 3.0 released in 1995, runs on 32-bit and 16-bit versions (Win3.1, WFW3.11) as well as the Macintosh, but does not provide
complete ANSI SQL or COM server building capabilities.

Inheritance is automatic in VFP

Inheritance is the language mechanism which allows the definition of a class to include the attributes and methods defined for another more general
class. Inheritance is an implementation construct for specialization relations. The general class is the superclass and the specific class is the
subclass in the inheritance relation. Inheritance is a relation between classes that enables the reuse of code and the definition of a
generalized interface to one or more subclasses.

Using inheritance:
Since it is not possible to modify the VFP base classes, it is a generally accepted practice of developers to subclass all of the available
BaseClass 's. Let's call these new classes the 'developer base classes'. These classes can then have custom code added to the methods
and events and also custom properties added to these new BaseClass 's. All new classes should then be subclassed from the developer
base classes.

Types of inheritance:

Adaptive inheritance happens when you use a subclass to change a property or the workings of an existing event or method by:

Overriding the parent class behaviour,
pre-processing (and possibly overriding) the parent class behaviour,
post-processing the parent class behaviour,
or both pre- and post-processing the parent class behaviour.

Extensibility Inheritance happens when you subclass and add new properties and methods to support new functionality not found in the
parent class.

Recommendations:

Don't port FoxBase or FoxPro code to VisualFoxPro. It is inefficient and does not take advantage of the benefits that VFP has to offer that were simply not available when FoxBase or FoxPro was created.

Scott comments to Universal thread : Someone doesn't know what they are talking about. I think the expert users on universalthread know best but I have be armed with hard facts probably supported by microsoft. They copied someone from microsoft throughout the e-mails, the address was darrster@microsoft.com.

Thanks again,


Scott