>>>Everything you describe here could be done already... You may have to write your own metadata layer, but I feel certain you could do it...
>>>
>>>What do you think most people want?
>>>
>>>1. Improve the X-base'ness of the product
>>>2. Improve the integration with ADO/OLE-DB, SQL-Server, etc....
>>>
>>>My guess is that most folks would vote for #2...
>>>
>>
>>Obviously count me for #2 - an extreme 2, who'd like to see 3 - a reduction of xBASE behavioral support.
>>
>>>Jim Booth's observation is particularly good. In what you are advocating here, you would be making the migration to SQL-Server, Oracle, etc that much more difficult.
>>>
>>>As far as the conclusions you have reached regarding SQL in general, you know my stance on that....<s>....
>>
>>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.
>
>Hi Ed,
>
>It is not my area of expertise, but I wonder if VFP stuff providing backward compatibility could be technically separated from newer and better version of VFP and added to the package as separate DLL, so if somebody wanted the backward compatibility then s/he could add this DLL to the project?

Nick, I think I love you! Yes, it's the same idea that Clipper used to have of including parts of the language at link time. The compiler needs to be smart enough to either mark the app as requiring specific portions of the runtime, and ideally, I'd like a lint-like tool that scans for non-compliance with the xBASE-free subset or subsets.

I suspect that much of the backwards compatible code uses some of the same code base as the newer stuff that replaces it, especially where it says "Included for backwards compatibility".

What you suggest would certainly be a good start towards cleaning up VFP - isolating the xBASE-ish pieces, and it'd let you enhance one side without undue effect on the other. It (the xBASE piece) might even be a viable xBASE platform on it's own. I'm sure that the people who rely heavily on the xBASE side would love to have just that 600K plus the data engine components to make it all work.