>>I'd like to see VFP move into a marketplace where we give up backwards compatibility, strengthen the ActiveX/COM capabilities, and retain it as a strong interpretive language with the advantages of compile-on-the-fly, macro-expansion, name substitution and expression evaluation. A fast, powerful and flexible interpreter with strong data handling, that plays well in the COM environment definitely has a place in Microsoft's product lineup well into the future.
>
>Nobody will argue these points, but the focus of discussion was shifted tremendously (or purposedly). The point was that in some situations XBase approach provides better performance, nothing more and nothing else. If some approach happened to be called 'XBASE' it does not mean yet, that it's bad.

XBASE per se is not bad, but in general, expanding on the set of things done with the xBASE dialog, rather than migrating to the newer technologies, seems counterproductive. I certainly don't want to expand the xBASE-ish nature of the language for no real gain - everything he asks for can be done with the DE, and the more people move from xBASE, procedural thinking towards OO, set-oriented approaches, the more we'll be able to easily exploit new database technologies within the VFP framework.