All of this is already implemented in .NET or C++, Function overloading and Strong typing.

VFP would benefit from these features but it would be a major change to implement and still have backward compatibility.

We already have since VFP 7 some type of strong typing to be compatible with other COM Servers or clients. But it not enforced whithin VFP other than i works with Intellisence.

>First of all, you could have a VARIENT variable type (which would be default, say, unless a SET STRICTVARTYPE was set at compiletime), which could be anything. So this would still work:
>
>

>LPARAMETERS tvFirst, tvSecond
>DO CASE
>  CASE VARTYPE(tvFirst) == "N"
>    ...
>  CASE VARTYPE(tvFirst) == "O"
>    ...
>...
>

>
>BUT, you could also have code like this:
>
>

>FUNCTION DoSomething(nNumber STRICTAS Number)
>FUNCTION DoSomething(cNumber STRICTAS Character)
>FUNCTION DoSomething(vNumber STRICTAS Varient)
>

>
>So, Code like this:
>

>DoSomething(nNumber)
>DoSomething(cBlah)
>DoSomeThing(oObject)
>

>Would all still work, as any variable type can be changed to Varient. That would be pretty cool, no?
>
>The only problem it would cause is FoxPro would have to search all possible/available functions, before it could run the function. So, you would need either something that specifies to not search outside the APP/EXE, OR, something like a function to search and build a list of available functions, which would still slow VFP down. For example:
>
>

>* These could possibly call different functions, but "@DoSomething"
>* would be faster, because the compiler can mark which function to use.
>* There are a lot of issues here, actually. Anyway you look at it though,
>* making VFP have these kinds of strictness is going to make VFP much slower,
>* unless a lot more happens at compiletime.
>@DoSomething(cSomething)
>DoSomething(cSomething)
>*OR
>DoSomething(cSomething)
>VFPReloadFunctions()
>DoSomething(cSomething)
>*Could also run different functions
>
>-----
>
>*Consider this code!
>DoThis("1")
>
>Function DoThis(tcValue STRICTAS Character)
>LOCAL cValue STRICTAS Character
>
>cValue = EVAL(tcValue) && Can't be evaluated until runtime
>
>-----
>
>* So what does foxpro do? Error? Not assign anything?
>* This adds a great deal of potencial complexity. Of course,
>* it also eliminates a great deal of complexity, as the compiler can catch
>* a bunch of mistakes, like this:
>
>@DoSomething(1) && Ooops! supposed to be "1"
>FUNCTION DoSomething(tcToWorkOn STRICTAS Character)
>
>* Of course, you must have the "@", or the compiler has no way of knowing
>* that you don't have an external program named DoSomething.
>* Actually, a SET STRICTCALLS makes sence here...
>* Or perhaps:
>#PRAGMA STRICTCALLS ON
>*(also a SET STRICTCALLS for a default. PRAGMA would apply only to that method)
>* This errors if there's no "FUNC DoSomething(cParameter STRICTAS Character)"
>* or "FUNC DoSomething(vParameter STRICTAS Varient)" or compatable function
>* in the APP/EXE
>LOCAL cStuff STRICTAS Character
>cStuff = "Stuff"
>DoSomething(cStuff)
>#PRAGMA STRICTCALLS OFF
>* This doesn't error until runtime. I doubt that most developers would have
>* PRGs in the runtime directory, so they could just have STRICTCALLS on all
>* the time.
>LOCAL cStuff
>cStuff = "Stuff"
>DoSomething(cStuff)
>

>
>Ok, that's a big enough post. What does everyone think?