>
>Firstly, a VFP.NET would necessarliy be a subset of VFP proper, as I understand it. My point was that VB already has subsets.

VB subsets will be going away. They will all become just VB .Net.

>VFP could too.
>
>"Burning the VFP Team's resources" is a problem of mine???? Does that mean that those responsible for the selection of "features" to add to VFP6 are now in purgatory or elsewhere?!?! Making and maintaining a VFP.NET in addition to regular VFP might be a huge job or it might be a piece of cake. I have no idea.

It would mean sacrificing features forever. If you add a feature to the non-managed VFP, you have to add it to the managed code. This means twice the work as long as both versions exist.

>
>>We'll never have time to add features to the report writer if we had to compile to the CLR. (Disclaimer: the previous statement was an attempt at humor. Call it sarcasm, call it facetiousness, call it what you will, but it implies no promise of any new features for the next version of VFP.)
>
>My main point is that people who are intimate with VFP will naturally ask for a .NET version rather than simply accept that the have to LEARN another language. Is it so hard to grasp that people who worked hard 'getting' the subtleties of VFP don't want to spend an even greater amount of time learning the same for yet more languages and facilities???? Is it that hard to grasp that people do not want to be in the 'minimally capable' category for expertise in a language for years to come? Especially when we have much of the real object orientation (and its concomitant constraints) that is proving so bothersome to the VB folks.

I disagree. I do not want a VFP .Net. Many others have expressed the same thing. It was very clear last year at the Miami DevCon that the Fox community did not want a VFP .Net.