>>>>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.
>
>I disagree that set-oriented approach is perceived as identical to OO approach. Actually, record-oriented approach can be done in OO and non-OO ways, and the same is true for set-oriented methodology. Actually, your reply gives a clue here: if DE can implement many of these things and DE itself is part of OO-paradigm, then the whole way can get OO-implementation.
>I don't mean that MS should do it. As I said in some other reply, I interpreted Walter post as the hint that it's doable on developer's level, and it could be Ok. Personally, I don't use about 50% of commands he mentioned :-), but it still could be Ok, if it's done properly.

Ed, you can write OO record-oriented code; you can write procedural set-oriented code. The native OO tools in VFP work well with view-oriented, set-oriented processing, and portability of the data services layer of the application to a backend environment is significantly easier if you already think in terms of SQL DML operations. Rather than add yet another xBASE layer that does nothing more than emulate set-oriented behaviors, I'd rather see the VFP team strengthen the native SQL support to do things like nested subqueries, and give VFP the ability to deal with ADO recordsets in the same fashion as it deals with native cursors, making it a better player in the distributed computing, COM/COM+ environment.

Judging by what I'm seeing for new projects, fewer and fewer of the projects I'll be working on are going to be pure VFP applications. I anticipate doing more with ADO and XML, since these will cross over COM boundaries easily. It's going to be important to me to be able to switch in a different data engine without having to make major changes to the entire system. All of these things are aided by using standard SQL DML throughout the project's lifecycle. My UIs will be much more diverse as well, and will included classical thin-client and Web-centric interfaces, where tools other than VFP's form designer are a better fit. I'd like VFP to play better in this environment.