Ed,

>I'll stand by the statement that this is not something VFP does well -

It really on how "well" is being defined.

> but that the work to implement it

I'd say that work involved, in terms of "amount" of code actually is smaller in VFP than it is in other languages

> and the overhead involved, is excessive.

A VFP object definately has a larger memory footprint. I think that's only truly significant when you are talking in terms of thousands of objects though.

VFP's biggest overhead fault is it's interpreter based execution. So if execution time is the prime factor use a C derivative language.