>Ed,
>
>>>What do ya think. Wouldn't this be nice ?
>>>
>>
>>Nope.
>
>Tell me why not ? Just saying NOT in a message is a message without a value.
>

I deal with things set-oriented, and avoid things like SET RELATION/SET SKIP as much as possible because of issues porting the resulting code to work with ADO recordsets or SPT. The more we burden future versions of VFP with the legacy xBASE methodology, the greater the risk of enhancing the product, and the footprint, an issue already for many people, will just keep getting bigger. I want a leaner, meaner, cleaner OOP environment and would gladly give up the old record-oriented ISAM behaviors to get it. We already see the little annoyances that creep in using things like filters in Report Writer output (typical problem - if you use a REPORT FORM FILTER clause with Preview, the Preview looks OK, but the filter is lost when you go to print) and differences in language behavior with things that on the surface at least seem related but are not because of scoping and encapsulation issues (why BROWSE with a FILTER clause performs well, while filtered Grids do not.)

I do not believe that in the long run a native file system will be a great benefit for application development. MS and others have moved more and more towards a data-oriented view of the operating system and file systems, and I expect that trend to continue as the Wintel platform develops. Integration of things like LDAP access to operating system features via ADSI, the use of XML and ADO as data interchange mechanisms for the OS, and a more database-oriented view of the operating environment all seem to point to a data-centric paradigm not just for the application, but for the system as a whole. As the OS relies more and more on native database tools, I firmly believe that there will be a database orientation to the base file system for the platform. If this happens, everything will have a strong native file system available to it, and the behavior of that file system will become uniform for all aspects and language platforms. We have a lot to learn from the AS400's operating system design.

IOW, I want to abandon much of the xBASE-y/ISAM-ish things that I feel burden the basic VFP engine in favor of a move towards a language which encourages moving away from our procedural roots. I like what I've gained in the shift to OOP and set-oriented operations, and would be happy to see less backwards compatibility in the next release, and certainly am against adding things to further perpetuate xBASE-ish programming practices.