James:
I am in a similiar situation to yours. I agree with your sentiment that it
would be nice to have a VFP.net implementation. My main priority is the expressiveness of the programming language that I'm working in, and for my
money VFP syntax is much more expressive that C#. Considering the disparate
modules (C#, ADO.net) that one has to become proficient in I long for the
unified environment of VFP.
It seems to me that since languages such as SmallTalk, Python, and Ruby have begun .Net implementations the strong typing issues should not be a hindrance.

Mike


>Hi All,
>
>Just finished my first (small) application in C#. Any VFPer who has learned C# knows that it is so close to VFP in orientation and philosophy that it is certainly much easier to move from VFP to C# that from C++ to C#. Were I not already familiar with OOP as implemented in VFP, I think C# would be a struggle to understand.
>
>In fact, it is easy to conclude that C# is fundamentally VFP with odd syntax. The marvelous 'innovations' in C# have direct analogs in VFP. Compare, for example "Using ...;" to "SET LIBRARY TO ...". Just another way of accomplishing the same task. A lot of comment I have read makes much of the fact the VFP allows function and C# does not -- everything in C# is a class. Actually, if one creates a class called "functions" and puts all the typical user defined functions in the class, there is not much practical difference.
>
>Which leads to the question, Why not VFP.NET?
>
>What would be required to make VFP work as managed code?
>
>1. Strict variable typing. Not much of a problem. All migrants from Clipper have been through the experience of converting all their code written for versions prior to Clipper 5.x to use strict typing. As I recall, it did not result in great mahem. Enforcing strict typing so errors are caught by the compiler and not by the customer at run time is a very good idea in any case.
>
>2. Commands restated as Functions. Again all writers in Clipper 5.x remember when Clipper eradicated commands and introduced equivalent functions. USE.... became USE(). It does not require much mental adjustment to make this change. Don't we usually wrap common commands in user defined functions anyway, if for no other reason but to return an indication of whether the command was sucessfully executed? Commands are an anachronism that should be exterminated in any case. Native functions would be a better choice.
>
>3. CLR Compiler. Instead of compiling to p-code, how much more difficult would it be to compile to Common Language Runtime? It seems to me not to be a practical problem, but a political one. Someone just has to allocate the resources to do it. We could have the choice of a p-code or CLR compiler -- pick it from an IDE menu. Again, back to my Clipper experience, I remember we had a choice of at least two compilers. There may have been others that I never used.
>
>So, Microsoft, what is the problem? Wouldn't this approach make VFP much more mainstream and do a lot to reduce the constant VFPer complaints that Microsoft is not really supporting VFP?
>
>I think it would, and would add a powerful development to the .NET repetoir.
>
>Or is there an insurmountable problem that I just don't see?
>
>Regards,