Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Microsoft's position on Visual FoxPro and .NET
Message
From
14/06/2004 11:33:49
Emmanuel Huybrechts
Technimeca International Corp.
Montréal, Quebec, Canada
 
General information
Forum:
Visual FoxPro
Category:
Conferences & events
Miscellaneous
Thread ID:
00908177
Message ID:
00913490
Views:
84
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.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform