>>I am wondering: What are you saying "Nope" to specifically?
>
>To everything. :) Basically, you're speaking about composition, not inheritance. More precise, the inheritance for a composite class, which is different than a class with multiple parents.

Paul, you are arguing terminology. I am not. Pick a statement I have made and tell me what is wrong with that statement. I have not put a label of anything I have said. You have.

Even so, if I had said

5+5=10, this is an example of division

you would say "Nope to everything." Well, you are wrong. 5+5=10 and that is true.

>
>>Are you saying that in the example I gave, TestClass class does NOT inherit properties from two classes? It does, right?
>
>No, it doesn't.
>
>Let's say that A is based on a container and contains two objects of classes B and C. Our TestClass is derived from A.
>
>Class B has a BProperty and a BMethod.
>Class C has a CProperty and a CMethod.
>But class A doesn't have any of the above PEMS. Class TestClass derives from A and it also doesn't have any of these PEMS.

If you make a change to a property in Class B, Class A inherits that change. If you make a change to a property in Class C, Class A inherits that change. And Class A does contain these PEMs. There can be accessed by ClassA.ClassBObjectName.BProperty, etc.

>
>If TestClass would inherit from B and C (as it is required by multiple inheritance), you could write
>oTestClass.BMethod()
>oTestClass.CProperty = 4
>but this is not legal in VFP.

Paul, I think you should review the discussion. Nobody ever said VFP supported multiple inheritance. The word simulate was used.

>
>It's true that TestClass inherits the B and C objects (this is still single inheritance) as it does with any other PEM of class A (contained objects can be seen as object reference properties).
>
>So, TestClass inherits only from A, not from B and C.
>

And A inherits from B and C, correct? So a change in B will be inherited into A, correct. And that will then be inherited into TestClass, correct?

>The fact that you can change the code for the methods of the contained B and C directly in the class designer is only a shortcut in VFP. If you want to put it into strict OOP, this would be translated to:
>-B1 derived from B
>-C1 derived from C
>-TestClass contains a B1 and a C1.
>Something similar happens if you change the same methods directly in A.
>
>But, as I said, this is not pure OOP (because, when a method is overridden, the class is no longer the same, so, it's a derived class in fact.) But this burden is hidden in VFP and makes many tasks simplier. It also accounts for the many and difficult problems one can run into when container classes are derived.
>
>In other words:
>Inheritance is a "is a" relation, while composition is a "has a" relation. In this case, TestClass "has a" B and "has a" C, but TestClass "is not a" B or C.
>
>>Also, in this example, it is possible to override any method form either parent class.
>
>See above. The overidden methods are not from parent classes, but from contained objects.
>

How about this, it is possible to override any method. The methods from the contained objects are from the parent classes.

Assuming no overriding methods: If you were to change the method in the parent class, say B, the change would inherit right down to TestClass. If you were to instead make the change in the instance of B in A, the change would inherit down to TestClass. If you were to make the change to the parent of B, the change would inherit down to TestClass.

>>What does happen when you have parent's with the same properties and methods and they conflict?
>
>I assume that, depending on the language, there are rules that clarify such conflicts. The only language I know that supports multiple inheritance is C++. Any rule that eliminates confusion is good.
>

I would assume the same thing. So, what was your answer? Actually, don't worry about it, someone else answered.

>>I am still not convinced that some of the uses of multiple inheritance can't be simulated in VFP.
>
>The uses can be simulated. But only simulated. For example, in the above example, the programmer can define the BMethod, BProperty, CMethod and CProperty for the class A. The new methods would call their correspondents from B and C, while the properties can be inherited using accessor functions (yet another great use of accessors!). But this code must be written and it may imply A LOT of code and A LOT of maintenance.
>
>Multiple inheritance would make it by default with no code necessary.
>

But, why would you want to do this? This entire object is based on multiple objects that are designed to co-exist. Put the new PMs into the container. They can do what they want to the other objects from there. I understand where this argument would make more sense with Events. But we are outta luck there.

The initial point was that multiple inheritance could be simulated. You've agreed to that several times. The argument has lost its focus and is now concentrating on definitions and theoretical what-ifs. Well sure, you can argue the definition of simulate. You can show that to simulate some abilities it is difficult. But, I have yet to see a practical example of multiple inheritance that cannot be simulated easily. By practical, I mean something like this: Given this real-life objective, we use this solution. Saying, "You can do this" before you have a "Why do you want to do that?" is not something in which I have any interest.

Take care,
Joe