Hi Don,
If you strip out all of the xbase stuff and only implement the portions that are readily provided by the .NET framework then you have the same problem that VB developers ran into plus you've lost a bunch of functionality and speed (the functionality and speed that makes VFP valuable) in the process. MS isn't going to do it (create VFP.NET) because the added market share they'd reap wouldn't come close to justifying the resources they'd expend. MS has been known to throw money away before, but I suspect the bean counters that said yes to VB.NET are not about to say yes to VFP.NET. However, that doesn't mean that I don't like the way you think...
The way this WOULD work is as a community open source project where something more akin to what was done with Visual C++ is the goal. Managed and unmanaged code to be more specific. A parser/compiler for Visual FoxPro code that produced Common Intermediate Language (CIL) could be done which could then be compiled into .NET assemblies. The VFP commands and functionality that doesn't exist in the framework would be compiled as it is now. The parser/compiler would require tons of effort, but it's not impossible. There would also need to be some extensive work done in the VFP IDE (add-ons, scripts, new code editor window, etc) to provide intellisense and other basics that devs take for granted so it was suitable and productive to develop in.
That all having been said, what are the arguments for such a project as opposed to using .NET Interop and writing the managed code in C#, VB.NET, or other and the unmanaged code in Visual FoxPro as is routinely done now by some VFP devs? Bit of a rhetorical question as in my mind a project of this magnitude for VFP would, at the end of the day, chiefly serve to positively impact the market's perception of VFP. And that would only happen if the implementation was really well done and not some half-baked proof-of-concept.
Worth the effort? I've been toying with this idea for over a year now (probably closer to 2 years)... I still don't know the answer. The logical part of me is pretty sure that the return on investment would not be as good as some of the other things that could be done right now for VFP and it's future. But, the emotional part of me thinks writing a parser and compiler for VFP that would produce CIL would be tons of fun, exciting, and would serve as a suitable way to help continue VFP well beyond what MS had envisioned for it. The VFP 9.0 runtimes could stay as is and the community would have another avenue for improving VFP by virtue of the parser, compiler, and the .NET framework. However, their again this can already be done with .NET interop and in extreme cases by emitting CIL and compiling assemblies in memory to run C# and VB.NET code directly from VFP. So, the real net gain (no pun intended) would be in the perception of VFP. Worth the effort?
>A discussion on another thread got me thinking about what I like in .C# .Net and what I like in VFP. The thought came into my head, that many programming languages, the ones developers really like, were not developed by the mega corporation. Fox Technologies is an example.
>
>So why can't we have a VFP(xx) platform that compiles on the CLR, runs within the Visual Studio IDE? Why not?
>
>Consider:
>1. What if the legacy xbase commands were stripped out of VFP(xx). This version would not run Fox code compiled on earlier versions of the language.
>2. The VFP data engine was omitted, but VFP(xx) was designed to use a backend, such SQLExpress or SQL, mySQL or VistaDB.
>3. It compiled to an intermediate language that ran on the CLR.
>4. The new Fox language remained data centric, within the above constraints.
>
>THEN: Why not include VFP as a .Net language? Microsoft could do this easily. (ARE YOU LISTENING MS?) If you think about it, they kind of had to do something similar to get VB into .Net.
>
>However, I think the opportunity is for a fast agile small firm, headed by a genius like Dave Fulton. After all, the CLR is open source.
>
>Regards,
>Don Lowrey
