Hi Walter,

I simply can't comment on any enhancement requests but I promise that they're all being considered.

>>
>>Strong typing is essential to .Net but not VFP. Personally, I don't think the arguments extend to VFP as we do quite well without it. OTOH, I can't imagine a .Net app without it but that's mainly due to structures peculiar to .Net itself.
>
>Sure, that was what I was trying to say here: Strong typing is not neccesarely better than weak typing. In fact I think in many cases weak typing could be way more 'developper friendly'.
>
>Anyways, as a Microsoft representative, do you have any comments on my IDE wishes below for VFP10 ?
>
>Walter,
>
>
>>
>>>I've seen lots of comments on the merit of strong and weak typing. This is of course also on topic that is discussed when talking about differences between VFP and .NET.
>>>
>>>Strong typing has always been the area of fast and low level languages, like C, C++ and pascal, etc. Weak typing has been used in easy to learn languages like Basic, DBase, FoxBase etc.
>>>
>>>It begs the question why do we use strong typing. Many heard arguments:
>>>1. It allows the compile to create faster code.
>>>2. It allows to track programming errors at compile time.
>>>3. More recently, It allows better intellisense solutions.
>>>
>>>Now lets discuss the matter point by point.
>>>
>>>1. It allows the compile to create faster code.
>>>It is a given fact that you can create faster solutions where the compile can determine the type of the variable. This fact is important for a whole scala of applications like OS's, device drivers, lowel level math intensive applications, etc. Currently with the processing power of today it is less important for a lot of data(base) applications. Whether the user has to wait for 1 microseconds for an answer to a question or 1 millsecond. The user won't notice the difference. A lot of parts of you application are not that performance depended that they absolutely have to have the higher performance. So in most circumstances, from a performance POV it really does not matter to write a database application in a strict typed environment or in a weak typed language.
>>>
>>>2. It allows to track programming errors at compile time.
>>>In weak type languages you're allowed to create variables of any type at any time. You don't have to declare a type at the beginning of a language. The compiler therefore has no idea what type of value a variable contains and cannot judge whether a command line would cause a problem at runtime. This is a much heard argument in favor of strict typing: It prevents bugs by detecting them at compile time.
>>>
>>>However, strong typing comes with a cost. You'll have to declare them at the beginning of the code and casting between types often has to be done explicitly. I've got some experience in C/C++ and everytime when I did a compile of a piece of code, I got a bunch of errors because of type mismatches. Some were easy to spot and solve, others where more difficult, esspecially when it came to OOP. Because of the problems of strict typing yo'll have to use virtual functions and overloading in for example C++. Such languages are not particular well suited to implement quick and dirty (prototype) solutions. I often got the idea that strict typing caused more trouble than benifits.
>>>
>>>This begs the question: can we use best of both worlds? Enable the detection of undeclared variables or mismatches, but not having to jump through hoops like difficult operations like explicit casting, virtual functions and overloading ?
>>>
>>>The first question to ask is: Why do we have to check for mistakes at compile time ???? Traditionally all compilers allowed to use any editor to write source code in (remember VI ??, ughhh): there were no smart editors. Later we got syntax colouring, so at least we could see if we made a spelling mistake in a command or function. With VFP9 we've got command line compilation. This is another step on preventing making programming mistakes.
>>>
>>>Would it not be nice if for VFP10 we would have hints for valiables not declared at the beginning of the code (e.g. with a red line under the variable (like words' spelling checker?). What about only taking a rightclick on such variable, poping up a dialog in which you can specify the type and scope. At confirming the dialog, the neccesary LOCAL, PRIVATE declarations are made at the top. Possibly we need a new extension to the EXTERNAL command, by declaring that a variable is external to the code and of a specific type.
>>>
>>>Last but not least, If we could have a compiler switch that generates warnings about missing variable declarations (in stead of errors), we would have about the same advantages of strict typing languages but not the disadvantages because the compiler itself does not care at all about the type of a certain variable.
>>>
>>>3. More recently, It allows better intellisense solutions.
>>>While VFPs solution is not perfect, it proves that intellisense type checking is not exclusively the area of strict type languanges. In VFP I could also declare a variable LOCAL x as Integer, or oWord as Word.application. To be honest I could perfectly live with that.
>>>
>>>
>>>Conclusion.
>>>I think it is time to rethink our standpoint on strong vs weak typed languages. Though strong type languages would still create faster code, the claim that strict typed languages creates safer code should be reviewed. It is not neccearely a benifit of strict type languages, but rather a shortcomming in the implementation of a weak typed language. Weak typed languages could provide the same benifits in error checking as strong type implementations. In fact the proposed solution above IMO is far better than the current checking at compile time one in strong type languages.
>>>
>>>Any comments ?
>>>
>>>Walter,