Generally, type-safety makes things more structured, and some would say more restrictive or more difficult.

However, let's take the example below again. I could pass it 2 strings, and the function would behave correctly (I assume... from the code, I can not tell). I can pass it two numbers, and it would return a number. Execution would not fail, but instead continue with some unpredictable results. It is easier to code your method, but it is much harder to make it work right.

In general, no matter whether a language is strongly typed or not, it is not possible to switch between types without getting into major logistical nightmares. VFP will let you get away with a lot, but I do not really think that VFP programming is easier, just because it will allow you to make mistakes without being able to even warn you about it.

As for the databases: They are generally strongly typed. For instance, you can not assign a number of a string field in a VFP table. The VFP compiler can not verify such things, but during runtime, you get strongly typed behavior in this case. Kinda the worst of both worlds. If there is one scenario where true strong typing has very little impact, then I would say it is the databases... ;-)

Markus


>Yes VFP is not type-safe, but not having to bother about the data types is often what makes Foxpro so easy to program. Being strongly types is also what's make .NET more difficult to work with databases.
>
>Of course, the downside of the VFP approach is that "incorrect data types" error are not catched at compile time.
>
>>Your example is less code, but it is not type-safe. I can pass no parameters, or one, or two, and I can pass whatever data type you want. If I pass your function two numbers, it will crash, but you will not be able to find that problem during compilation. In fact, if I am a smart hacker, I can probably force your program to do unexpected things that it wasn't supposed to do. Not a particularly big issue in VFP, but still.
>>
>>A non type-safe program is not controllable from the outside by a runtime environment. If you make an error programming, then the system will crash or perform in unexpected ways. That is not considered "trustworthy". Since trustworthy computing has become such a big issue, this is a big deal.
>>
>>Of course, people *can* improve a function like the one you show below a lot, but: 1) Nobody has the time to add all the code to make such a function type-safe, and 2) as you can see in your example, nobody even things about it.
>>
>>As a side-note: If you add all the code that is required to make sure that your function below operates correctly in 100% of all cases (or close to that), you need to write a lot more code than in the .NET version. A .NET version will also be much faster, since the VFP version has to inspect meta-information such as types and parameter counts.
>>
>>Markus
>>
>>
>>>>Overloaded method are not so bad. For one thing, it can lead to more elegant code because you can have different code for a different list of parameters. And thus, you don't have to write lines like this :
>>> I didn't say that so bad. Only I said I don't needed in in VFP. Usually overloaded methods do some in most situations, so at worst in VFP you have to write a case or if in first lines like in your sample.
>>>
>>>>

>>>>FUNCTION Test(Param1, Param2)
>>>>DO CASE
>>>>CASE PCOUNT() == 1
>>>>   ** do this
>>>>CASE PCOUNT() == 2
>>>>   ** do that
>>>>ENDCASE
>>>>

>>>>
>>>>with overloaded methods, you can write :
>>>>

>>>>FUNCTION Test(Param1)
>>>>  ** do this
>>>>ENDFUNC
>>>>
>>>>FUNCTION Test(Param1, Param2)
>>>>  ** do that
>>>>ENDFUNC
>>>>

>>>>
>>>
>>>
>>>What is the different? I can't see. But in vfp I can do that:
>>>
>>>

>>>FUNCTION Test(Param1, Param2)
>>>   if PCOUNT()== 2
>>>      param2=iif(type("param1")="C","",0)
>>>   endif
>>>return param1+param2
>>>

>>> Look at that. Code lines fewer from a overloaded method.