>>>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.