>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, 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, and the first run of testing finds more than 90% of the rest. That's among the first things you find. For the special cases where you really want to pass some loosely typed parameters...

>>I don't have to write twenty versions of the same method to accommodate all the variations in parameter types.

>Writing twenty method signatures implies that all may be required. If you prefer having a single method that can handle all of those combinations then you have a *heck* of a lot of checking to make sense of the parameters that were received.

... you don't have to check for each combination. One parameter at a time, not one combination. If I'd have to check for combinations... I'd rethink my design :).

>Having said that would you dream of writing a method that required twenty parameters? Unless maybe it was intended for COM I''d be wrapping them in a single manageable object.

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.

>IAC C#2010 has named parameters and default values so you could take the single signature approach if so inclined...

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?

>>There's not much of a job to reconcile the types, if we talk about the basic scalar types (I don't care what kind of number it is, for example, because conversion is automatic). If we talk about classes, well, my job is to use the interface I have, i.e. to know the method names, which parameters to pass etc - and I think it's not my job to worry if I'm using wrong size integer or wrong type of string.
>
>So you have a method that takes twenty parameters and it's your job to remember the order and type of all of them?
>Good luck. Speaking personally I've got better things to do with my time :-}

If I get to six parameters, I'm off for a beer. Don't remember if I ever got to seven.

>I didn't look at the source on that link but from the description there doesn't appear to be anything involved that would not be easily implemented using .NET. If I get I chance I'll take a closer look.
>But speaking in general if you are confronted with an unknown type in .NET then Reflection is capable of providing a lot more information about it's members than can GetPem() and PemStatus() in VFP

All the examples in (http://en.wikipedia.org/wiki/Reflection_%28computer_science%29") the Wikipedia article on reflection are about creating an object via reflection and assigning it methods post festum (well, not in C#, there it invokes class level code), which still looks more like just a factory, not handling a generic object passed as a parameter. So, how do you handle things like this:

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