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

Then with who are you arguing?

>
>>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! :)

I know what the word everything means. I looked at my post and I know there were true statements. So I don't know what you 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.
>

I think arguing definitions is an ineffective way to make that point.


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

So, if it isn't inheritance, what is it? I change B and A changes. What do you call that? And just to be clear, A is a class that contains a Container class (whose class hasn't been named; lets call this class D), a B class, and a C class.

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

I have defined the class A to contain 3 things: A container, a control based on class B, and a control based on class C. If changes are inherited into something, and that something is part of a bigger something, I would say that the bigger something (not the container, the class containing the container and the other two objects) inherited the changes.

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

I think this is something that could be handled in a custom form method. Loop through all the objects in the form and if they have a caption or label property, change it. Use a recursive call to handle containers. While I don't think this is simulating MI, at first thought it would be the way I'd handle it. If you really wanted to simulate MI here, you'd have to create a transparent container with translation code. Then subclass that into a class containing that container and your other control (one for TextBox, one for CheckBox, etc.). Then, whenever you changed/fine-tuned your translation code, it would apply to all the other classes.

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

Again, this is theory. I can't think of a reason why I'd want to do that. But, by adding a method to an application-wide class with the generic code and adding a few lines and maybe a property to the application's classes, I think this could be simulated.

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

If there is only one example of composition simulating MI, your statement is proven to be false. Do you really think there is not at least one example where the use of composition simulates the use of multiple inheritance?

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

This is refreshing. Unfortunately there are people who will consider a statement like "Everything you said was wrong" to be insulting.

Joe