>For the above reasons, I see why inheritance is not part of COM. I also see why MS continues to skirt the issue of implementing it in VB aside from the complete re-engineering necessary to do so.

I think we will see VB get inheritance in teh future. Inheritance is part of OO. The problem is that it is often overused for specialization through subclassing to the detriment of other more versatile methods of specialization.

>
>However, the rhetorical nature of my question is valid when one considers the number of times that members of this very forum have pointed to inheritance as a key advantage of VFP over VB in Visual Studio. Now, many respected members of this same forum seem to downplay the value of that very feature.
>

I wouldn't necessarily call it downplaying inheritance but rahtr pointing out that it is not the ONLY method for specializing behavior in an OO design.

>If VFP provided the DODEFAULT as the developer added code to methods of a subclass, would this not address the issue of the developer having to know the details of the parent class implementation? Would this not then provide a more "black box" approach to developing VFP apps?

If VFP did automatically add a dodefault then we would need to remember to move it or remove it according to our desires. It is really no better only different.

The automatic adding of dodefault would have no impact on the fact that to specialize through inheritance you need to know what the parent class code is doing. You would still have to decide whether the default behavior should execute before your new code, after your new code, or sometime during the new code. To make that decision you need to know, not only, what the parent code does but to a certain degree how it does that. Needing to know what is does is not a biug problem, but needing to know how it does is a big problem as it locks the parent class' code up. It causes potential problems if the parent class code is enhanced or altered in the future. Becuase the child class code is dependant on the implementation in the parent class, changing the parent's code may require changes to the child's code. It is this dependency that makes inheritance a "white box" solution.

>Many of those who responded had valid responses and a more detailed knowledge of OOP theory than I have. However, they, like many VFP developers, tend to be the "one man show." Thus, from my perspective of team development, I still believe that I have a valid point. It's easier to bring in new team members, both experienced and new to VFP, without providing much instruction on the inner workings of the class libraries in use...

Therefore you should limit the dependenc on inheritance in specialization. Use other design patterns like strategy, bridge, factory, etc. instead.