>Jess,
>
>A few questions.
>
>> Majority of my colleagues here want VFP to be .Net language.
>
>First question, what is a .NET language? Is it a language that can consume .NET services? If so then VFP is already one.

It should compile with CLR..

>Is a .NET language a CLR langauge? Then why do you want VFP to be a CLKR language? What does being in the CLR buy you that you don;t already have?
With CLR you don't need

>> Regardless of technical reasons why it should NOT be, it doesn't matter and
>> we don't care.
>
>Interesting philosphy. We should just ignore all of the technical reasons for anything and just plod on.

Just for the reason of VFP not a .Net tool. I hate to see my .45 caliber pistol can't kill what other pistol can.

>> Why some of you keep on saying that we'll be losing majority of VFP
>> features?
>
>Because the CLR doesn't support them?
>
>> JVP said "...despite impressions to the contrary, VB .Net and VB are very
>> much the same. Yes, there are some differences, but in all material respects,
>> they are the same."

>
>I don't recall seeing JVP say this. I do recall him saying that in his opinion there was very little different between VB.NET and what a CLR version of VFP would most likely be.

See thread no. 587137

>> If VFP will not play with .Net as natively as VB, VFP religion will be gone.
>
>Playing with .NET and being a CLR language are very different things. VFP plays fine with .NET right now.

Yes, with WEB Services. With .Net Framework it's a complete package in developing Web apps. And you still have to consider DLL Hell. How about ADO.NET, ASP.NET?

>> We love the VFP community - not C#, not VB community.
>What does this have to do with VFP being a CLR Language?
Nothing. It's just that VFP users will truly diminish significantly...

>> For Independent Developers, learning another language is not a big issue,
>> maybe, but for software development company, it is a BIG one for economic
>> reasons.
>
>I don't understand why folks don't get it, if VFP were to become a CLR language you would have the same learning curve as you do with C# today. VFP under the CLR would be extremely different than VFP is today. Also the very things that make you feel so strongly about VFP are the things that would need to be different for it to comply with the CLR.

No. Then why COBOL, EIFFEL comply if they start from scratch and the learning curve is the same when learning C#? I've used VB6 for 2 apps and saw VB.Net a little and JVP was true with what he said to me. At least syntax are almost the same with different object model.

>> Lastly, I think making VFP.Net backward compatible with what it is today is
>> not more on a POSSIBILITY issue, but rather a resources issue.

If VC++ team did it (Managed and Unmanaged code) why not VFP Team? It's a resources issue Jim. Face it because that's the truth. :)