Hi Mark,

>Guess I'd have to see some timing tests to determine that. Especially since you're dispatching twice: once to find the "object" and once to do a string compare to find what "method" to invoke. All in interpreted code, not in the kernel. Macro substitution is notoriously slow.

Well, only for virtual methods. Macro substitution is indeed slower than precompiled code. You can speed this up by using Evaluate(), but of course you're right. I won't write time critical parts this way.

>Every time you add a new method, you have to change every derived "dispatch table" (and hope you remember where they all are).

No, I've to change only one table, that's the one in the class I change. Remember, when "subclassing" such a class, the OTHERWISE branch just passes every method it doesn't handle on its own to the parent class. If you've to change every program, I wouldn't dare to call this some sort of "OOP".

>You have to push five arguments on the stack on every call, even if the function takes no arguments.

FoxPro passes a structure of parameters to a function. And only the number of parameters give are actually passed. WIthin the function variables are created, and this are indeed, as many as you named in the PARAMETER statement.

>And you're out of luck if you have ten arguments.

Well, then you have to add 10 parameters to the dispatcher. *s*

> But the proof is in the pudding: has anyone ever actually programmed this way? :)

Depends. *g* I'd wrote some "classes" this way that are used in a FP 2.5 system. But I haven't wrote an entire system this way.

Christof