-snip-
>J.,
>
>At the risk of perhaps parroting Ed too much (which in and of itself may not be a bad thing< s >), what would be lost are the features that make VFP what it is. It is important to remember that it's the CLR that determines what features are available to a language. Currently, at least, these do not include things like a native file system.
>
>Further, VB is a general purpose language and VFP most certainly is not. Remove the data manipulation functions from VFP and, yes it could be a general purpose language, but since it isn't designed to be one in the first place, it couldn't hope to be as good as a language that was designed to be that in the first place. That's why I say it would be a bad version of VB.
>
>At the risk of starting a small firestorm here, I'll say that even giving the ability to produce both managed and unmanaged code would be of little, if any, benefit. I say this simply because of the above and why would I choose VFP over VB when producing a CLR compatible application? My familarity with VFP? IMV, that's not enough. I'd go for a tool designed from the bottom up for that purpose. Of course, it helps that I'm familar with VB (as well as a number of other languages), but even that isn't a compelling factor. Programming isn't about the language used. As Ed said, it's about problem solving and you go with the tool that's best designed to solve a particular problem. So if I need to munge data, I go with VFP. If, however, I don't, then I examine the problem, and make the determination of what tool is best suited for it.

I understand that there will be some things lost, but as with any change you would have to look at the tradeoffs. Moving to the CLR has its benefits and you would weigh that vs what you are giving up. Also I would theorize that people like the VFP toolkit for .Net author will find ways to bring back some of the features if the VFP team doesn't do it first.

And why would we take data manipulation functions from VFP? Can't they be used in a new CLR-compliant CursorAdapter class? or even CLR-compliant data manipulation functions for that matter. I realize I've gone theorizing too much here, my point is I don't think we are at a moment where we can say that native data manipulation functions will be lost. Maybe as they exist today they would be, but I'm sure an effort would be made to have something similar if that was the direction. Also we have to look at this issue from different perspectives, as not every application calls for a file-server-based database and data manipulation functions as it may not fit the architecture. Use VB for those? Why? I can do it in VFP even better.

I agree with your point of using the right tool, however the choices that a programmer has are not always that broad. Will I go learn C# for everything .Net or will I use VFP.Net if I had the option?

I guess I'm dragging the point too far out, so let me just summarize that this VFP programmer will not let VFP die if it went .Net.

Cheers,