>I'd rather have that chunk of code in one place, handling one parameter at a time, than having a dozen methods doing the same thing and doing it in a dozen places. How about this nightmare: do I have the versions of the method which handle each possible combination of parameters and their types?

This may be possible in VFP, but not in some other languages, which insist on declaring the types beforehand. Unless you use a "Variant" type, which is considered inefficient. (I am not sure whether a language like C++ would allow a Variant as a parameter.)

>Maybe I'm just too spoiled with VFP, but I still prefer having a few lines per each optional parameter, and using pemstatus() here and there when the object passed may or may not have a particular PEM that the code uses. The code is still all in one place, and I don't have to jump up and down the source like a sick monkey to locate the particular case that applies to my set of parameters.
>
>Then, another aspect is debugging: how can one be sure he's tried the call with all the possible sets of parameters? Somewhere down the road, a special set may be passed from somewhere down the chain which will break it by simply hitting a not-coded-for combination of parameters.

In that case - and again, talking about other languages, not VFP - you would get an error at compile time, not at runtime.

>One more: the overloaded methods should be doing the same thing for different sets of parameters. Are we sure everyone is following that sameness thing? The code may be wildly different. We may have a method which says "hello world" when passed a string, and the same-name method which says "go to where you came from" when passed a number. All syntactically correct, and within the rules, except semantical. Or, nine out of ten same-name methods do it the same way, one does it a little different. Go catch the bug.

It sure is possible to abuse this feature. But you can also write overloaded methods that do essentially the same thing.