>Paul, you are arguing terminology. I am not.

Precisely.

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

You know what I meant! :)

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

No, the B and C contained objects inherit the changes, not A.

>And Class A does contain these PEMs. There can be accessed by ClassA.ClassBObjectName.BProperty, etc.

No. Only the contained objects have those PEMS. Class A doesn't have them directly. You can test using the PEMStatus() function. Even the syntax that must be used (to access those PEMS) says the same thing.

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

I never said somebody said it! :) I only wanted to make very clear the difference between MI and its simulation using containers in VFP.

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

No. A "has a" B and a C. If I have a car, it doesn't mean I am a car. Inheritance is a "is a" relation. If the relation cannot be expressed using "is a" words, than it's not inheritance (as rule of thumb). But it may not be inheritance even if it's a "is a " relation.

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

The changes would be inherited in the contained members, not in the container. Basically, it's all about the terms we are using. Nevertheless, they have precise meanings.

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

Here's a practical example where I used multiple inheritance in C++:

I needed a multilingual UI framework (based on MFC) that would translate itself automatically when the language is changed. Simplified, I derived my controls based on MFC UI classes and one class that handles the translation in a generic way. (so, each of my controls is derived from one MFC class and my translation class). This way, I wrote the translation class only once and all the code was inherited in all derived classes. Obviously, in the real framework I wrote things are more complicated and my additional class handles more than the translation. But, this is the general idea.

BTW, the same thing could be developed in C++ using templetes. More elegant and simplier. But in my specific case, MI gave me other advantages, so I used MI.

This cannot be done in VFP directly. Still, VFP would allow for other solutions (probably a decorator or hook would be best) for this problem. But there is extra code that must be written in every class.

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

Let's say you want to add 10 new methods to all your 100 classes in a project. What do you do? All classes would behave in exactly the same way at the beginning, but it must provide the possibility to redefine any of those 10 methods in any class, at any level. As well as in any class that will be derived in the future from any of the existing classes.

Before starting to put all your classes in containers or to add members to all your classes, read the "Dangers of Composite Development" by Drew Speedie in FPA Feb 98. He discusses there very well the problems one can run into with container classes (a class that has other classes as members is also a container). This is just another reason for my statement that composition hardly simulates MI.

Finally, I want to add that in the whole discussion I wanted only to point out the difference (between MI and composition) and the fact that although doable, the simulation is difficult. I certainly didn't want to prove that someone is wrong with a specific statement or to offend somebody.

Vlad