>>That may be the main difference between the two different aproaches, and this is the main difference between VFP's inheritance and the VB interface appraoch.
>>Your' trying to simulate inheritance, but you've got to mannually take care of some things to accomplish the same inheritance VFP does natively.
>>
>
>When you override inhertitance with specific implementation code, is that not a manual process?

I'm talking about the inheritance mechanisme itself. Not the change of code. To accomplish the inheritance mechanism within VB there are things to take care of manually.

>>>This is the main point JVP and I argued about whether or not inheritance is of any value in a middle tier. John, solves inheritance related problems by using interfaces and doesn't call this inheritance. In fact he's right this isn't inheritance, but the motive to apply this construction is the missing of inheritance in the first place. I've not seen many VFP code which applies the second approach.
>
>Please do not twist the argument here.

I'm not, In the first message i send you, I said that inheritance can be of any value within middle tiers. I've been talking only about this issue.

>First off, my argument is not whether inheritance is of value in the middle tier. Rather, it is an argument of when inheritance is used, is it used for the right reasons. And further, the goals you expect to achieve will actually be achieved. Your kidding yourself - (there goes my unpleasant manners again) - if you think inheritance is an effective way to achieve code reused.

Well, I doubt if in the cases we've been trough OO would not be a right choice. I must admit that the same goals can be reached within VB quite easy, with the help of interfaces. Within VFP you have a choice, within VB you have not. Personally I can't see why i'd should use the interfaces aproach.

>I challenge you to show me a concrete example of where inhertiance in the middle tier really achieves your goal of code reuse. You already tried it once, and Jim Booth provided a convincing argument of why inheritance is not the bst way to go.

What argument, i've seem to missing it. JimB was pointing out that the models he provided are not that different, I can't see any argument to use the interface approach.

>Finally, to compare VB and VFP, lets say in VFP, you have a class that is subclasses 3 levels. There is a method that has code that only contains in the top-level class. I argue there is no real difference between VFP creating an instance of one of the subclasses and invoking that code and in VB, creating a class that implements the interface of the top level class, creates an instance of the top level class, and invokes the method. In both cases, the code resides at the same level, the top level. Was your approach automatic? Sure. Was the VB approach that hard to deal with? No. It took a couple of lines of code. In fact, no more code if you instead in VFP, provided the same behavior via design patterns.

I agree, but this is not the point I was (trying to) making.

>Walter, you view things entirely in the context of inheritance. I on the other hand, view things in a broader context, daring to say that inheritance is often not the right choice. That is the crux of our argument here.

Yep, I do, because to me this approach is more natural and is IMO an important part of the ultimate development language. If a certain language is missing this, i've to live without it (as for overloading and multiple inheritance within VFP.) and try to find alternatives.

>>Therefore I can only conclude inheritance can be of (a significant) value in the middle tier.

>Once again, I challenge you to come up with a concrete example here...

The example i gave about security has to do. I DO regard, Implementing the same behaviour with interfaces as a form of inheritance. With this said I stay with my conviction. This also implies that I do regard VB having some inheritance possibilities (by interface) by programming (thus not natively), though these mechanisms are quite limited when it comes to UI elements.

Within this context we would have no different standpoint IMO.

Walter,