I don't believe just because there are commands that had there origination in the non-OOPS XBASE world there is any reason to discard them. I believe that Fox enjoys quite an advantage, especially in data handling, over a lot of the so-called OOP's languages due to having the capability of its command language. I would be willing to bet that the proponents of more object orientation like Steven Black, Flash, and Ken Levy would not give of strengths of Fox due to it supposedly not being OOP's. After attending Steven Black's DevCon session I know that I need to make changes in some my implementation of design patterns and object orientation, but that does not include giving up on the commands that make Fox what it is.
-myron-
===============================
>
>I agree with you both wholeheartedly, and have some more objects I'd like to see. The following is a suggestion I sent to the VFP development team recently. I'd like your input as to whether this is possible, or even desirable. Admittedly, I know nothing about the internals of building a language or compiler. See what you think:
>
>I think a good way to draw new developers to VFP while maintaining
>backward compatibility would be to reduce the reliance on XBASE style
>code. Even though VFP is OOP, much of the code inside an object can still be XBASE in origin. You can still retain this for compatibility, but
>there should be an option in building a project (and coding) to disable
>backwards compatibility and XBASE style code. The debugger could
>enforce more object-like syntax. While things like set statements,
>sys commands, VFP's native sql and array commands are powerful, the syntax is not very easy to get used to, especially because the syntax can't be drilled
>down on using things like Intellisense. You could refine VFP's object model to have something like the
>following: