>>> VFP only supports part of the OOP specification. <<
>
>Which part doesn't it support? It may call some things by different names -- parent class instead of superclass, for instance -- but AFAIK VFP meets all the requirements of OOP. What am I missing?
>
>Mike

A lot, apparently. Operator overloading, multiple inheritance, the ability to raise custom events, pointers. The list goes on. VFP is a great language for hacking quick solutions, but for industrial strength applications nothing beats a pure OOP language. VFP supports the major portions of the OOP specification, but it was never intended to be a purely OOP language. It was meant for RAD environments where the full power of OOP is not necessary. VFP has its place almong the small company data management applications, but it doesn't have the kind of data security that SQL Server offers. Granted, of course, a client server application can be built with VFP, or even an n-tier model with a plethora of architecturs--web services, COM+, blah, blah. But there are times when using a fully OOP language is necessary. This is especially true in ultra-high transaction environments where memory mangagement is critical. I want to know exactly how much memory each of my objects are using. This level of control is not possible in VFP--build it light and hope for the best. I have made a good living with VFP, but I have seen it's limitations as well. Every language has them. It all boils down to the software development process and the use case requirements. You choose your tools around your requirements; you never bend your requirements around your tools. In my shop I have 15 guys working for me. Most of them don't know anything about OOP, and every last one of them is a dreadful hack in VFP. They all know it--most of them come from Fortran and C backgrounds. They still build applications that can run in VFP because VFP is very forgiving. Try doing the same thing in C++ and compile! We just ditched VFP in favor of .NET. Most of them are doing really well with the object oriented portions of C++ .NET and C#. Some are using VB.NET. The bottom line is .NET provides an integrated environment for using the tool of your choice. We standardized on C#, but we use the other languages when the requirements call for it. Nice! I'm sure I ruffled plenty of VFP diehards. I used to be one of them. I sat in this very forum and cried about VFP being the Microsoft Step Child from hell. Then I had to build an application in C++, and I realized what I had been missing all this time...The world is a beautiful place...