>It is true that inheritance is probably the single most overused feature of OO. While it is a necessary feature it is not the highest in terms of real reusability. One of the reasons for this is that inheritance requries a white box approach to class design. White box means that in order to specialize a class through subclassing it is necessary to now details about the the parent class's imlementation.
>
>It is not possible to specialize a method in a sub-class if you have absolutely no knowledge of the parent class's implementation. You must determine when, in the sub-class, to call the parent class code. That means you must nknow what that code is doing and what effect it will have on your sub-class's code.
>

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.

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.

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?

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...