Hi Ken,

we were also told we would lose all the dynamic language features. So, I figure, one "can't have" down, a few to go. <s>

When the "make it easier to use data" people get done, I figure they will come around to creating native data commands like, er, VFP. Which is at least somewhat the direction of X#/Xen. Speaking of which, I was told it didn't exist, not that it existed as a research language.

Anyway, what is relevant to me is that the barriers to making VFP a managed development platform, without losing functionality, are starting to fall. The dynamic language issue was one of the largest. Speaking of which: assuming Jim ports the entire Python reference implementation, which is the stated goal, native data handling will be part of that. Which won't be VFP data handling, but it will be native (to the language) data handling, and if it can be done in one CLR-based language ... IOW: the use of ADO.NET as a Visual Studio data handling methodology is a choice, not a constraint of the language.

As for the IDE: once Python has a "shell" (which is equivalent to our Command Window) (and assuming native data handling has been created), aselobj() (i.e., easy integration of builders) will be the main missing piece. And that's something that I know you've talked with the IDE team about (thank you, very much), and so I have some hope in that department as well.

So the big news for me is that dynamic languages will be coming to the CLR; and the secondary big news is that the language being implemented has native data handling as part of the reference implementation. Let a 1000 flowers bloom. <s>

Hank