>>This is immaterial IF we get a true .Net compiler. Microsoft has stepped out of the ring.
>
>Then it's not the core VFP product. In fact, it's not really VFP. It is a different product. Corporations will be somewhat resistant to it because it doesn't come from one of the big players.

I surely wish Etec would have a finished SQL-compatible layer just for database scripting the OOP way - but I am very afraid that the typical vfp user will not be satisfied with their offering unless it is 99% compatible, since the hoopla about the errors in vfp9Sp2 show the level of rigidity we reached as a group.

>What makes you think a .Net VFP app will be any easier to maintain than a VB or C# app in .Net?

From architectural POV many of the vfp apps are "worse", but the possibility to use less code makes that possible. One of the reasons I am interested in python is the "read/understand immediately" concept baked into much of the language, coupled with code not needing much redundant info.

>VFP is COM-based and COM tools and components are dieing. It will become increasingly difficult to interop between applications with VFP. Even today there are issues with web services, which are supposed to be an easy way, but VFP only supports BasicHttp and none of the WS* standards that add tons of functionality.

full ACK.

regards

thomas