>>>OK. Dynamic languages don't *force* you to check to type - but if you don't do so you haven't much protection against a run-time error.
>>>The best you can do is make it non-fatal...
>>
>>Since this kind of acrobatics is mostly for framework code,.....
>..who sez?
Just describing the typical scenarios where this my happen, from my experience. The code which needs to handle more than one class of objects is typically framework, or ends as a part of one. Not a rule at all.
>> where you want desired behaviors to uniformly apply to all of your controls, of course you have to test this thoroughly - and I've so far found that just properly prefixing the variable names covers for about 90% of type errors,
>
>Wha? sticking 'txt' in front of a variable name prevents type errors ?
>I suppose you could write a compiler that worked that way - but VFP isn't one of them.....
>I could prefix a variable name with anything I fancied - it wouldn't mean diddly-squat to VFP
It helps me. I usually take care to rename a variable if I initially gave it a wrong prefix. But then this kind of discipline is voluntary, not mandated by any compiler (and diddly squat is the exact measure of how much VFP compiler cares about that).
Still, I can't remember the last time I saw a "datatype mismatch" error late in the game. These are caught early on.
>> and the first run of testing finds more than 90% of the rest.
>And the next 10,000 runs could fail to catch any of the remaining 10%
So it is with any other type of bug, I don't see why type mismatch should be privileged.
>>I didn't say "20 parameters", I said "twenty versions of the same method", assuming my usual limit of 4, worst case 5 parameters. Once it gets to more than that, see previous paragraph.
>
>So,given the above, where did your scenario of needing to provide twenty overloaded signatures to a method come from?
From combinations of parameter types. With just two parameters, you can have (speaking in Fox data types) string+string, number+number, date+date, logical+logical, or 12 other combinations of just these four types. Or the overload in strongly typed languages works differently from what I think.
>>Not sure that would help much. It is a nice feature, don't get me wrong, even VAX assembler had it 25+ years ago, but then in code I'd have to check which parameters were omitted - pretty much the same approach as I now have in Fox, by checking parameter types. What if the default value was indeed sent? How do I distinguish that from omitted?
>
>Why would you need to distinguish? If a value is sent that's what you get. If it's not you get the default......
Pcount() function was written without a reason, then?
Though, I guess in cases where you want to know whether a value was passed or omitted, you can make null the default... but then what if a null was passed? Anyway, this one was more curiosity than anything else. I just wondered how this works. Fox was weird to me in its ability to call code with fewer parameters than required, I haven't seen such a language before, and now I realize this behavior made me adjust my thinking. It's a feature I learned to like, and I guess in any other language it would have to be done differently.
>>If I get to six parameters, I'm off for a beer. Don't remember if I ever got to seven.
>
>If when you get to six you go for a beer then, ipso facto, you don't get to seven.
>This not only sounds like a good rule of thumb but also a wise course of action :-}
>But if you only get to six then, as above, why do you need twenty method signatures ?
I don't, I write Fox :). See above.
>>
LPARAMETERS toObj
>>IF PEMSTATUS(toObj, "oGadget", 5)
>> toObj.oengine=this.oGadget
>>ENDIF
>>or this
>>
LPARAMETERS toObj
>> IF toObj.BASECLASS="Timer"
>> IF toObj.ENABLED AND toobj.interval>0
>> toObj.ENABLED=.F.
>> toObj.INTERVAL=0
>> ENDIF
>> ENDIF
>>
>
>I've run out of steam. If I may I'll confront this last bit tomorrow......
Instead of steam, try electrons... the technology has changed. Funny though, how it influences the language, eh?
