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

Ok. There were a smile sign after my "No to everything", but it seams you didn't see it. There are other smile signs in my messages in this thread. Please read them too, because they are part of the message and, generally, they want to say "don't take it too hard". Anyway, if you want me to analyse your message phrase by phrase, here it is:

>>>
I am not arguing, just pointing out that if you create a class (called TestClass) that has a container (based on a container class) and other objects (for instance, 2 buttons based on a button class) and the parent container class' proterties are changed, those changes are inherited into the TestClass class.
<<<
Incorrect, the changes are inherited only by the contained objects. In this case, the contained object is a container, but this doesn't change anything.

>>>
If you change properties in the parent button class, those changes are inherited into the TestClass class also.
<<<
Incorrect, the changes are inherited only by the contained objects, not the TestClass container (or any of its subclasses).

>>>
So this TestClass class does inherit properties from two classes.
<<<
Incorrect. See above.

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

Maybe. Definitions are the explanations for the words we use. And unless we use the same definitions... IMHO, definitions are extremly important because they define (finally) the meaning of our phrases, etc.

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

In this case, composition.

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

The fact that A contains a Container doesn't change the problem. BTW, I use "container" for any class that *has* other objects and not for VFP's Container class.

I know your first class (TestClass) has a Container that has other objects. I tried to simplify it a little bit in order to make more clear the relations between objects. This simplification doesn't change the problem.

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

If this "bigger something" is a subclass, the changes are inherited. If it is a container, the changes are not inherited.

Now, if you want to extend the definiton of "inheritance", it's your choice. But it would be your definition and the one that's generally accepted. Your understanding of inheritance doesn't make a clear difference between "is a" and "has a" relations.

>I think this is something that could be handled in a custom form method.

Correct. But in this case you move the translation from each object to the container level (the form in this case). This goes well enough in VFP where there is a limited number of base classes (for now, who knows what it will be in the future?). And it goes well if you own the framework. It doesn't work if you have to use an already existing framework where you cannot change the common base class for forms. It also doesn't take care of other containers (like toolbars, for ex.).

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

Probably I would do something similar. I just gave you an example where I found MI useful. I never said it's the only solution. And I already said that MI is rarely used even in C++ and that it must be used only when necessary.

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

This is real life, not theory. The real life problem may be: add automatic translation and look options to your X project. This requirement can easily involve 10 generic method for all your 100 visual classes (medium to big scale project?)

And it may come from the request for multilingual support because the project moves to international markets and some visual customizations that almost all your users require. You would like to say no because it involves too much work... but it also involves a price increase from 5 to 10 times (depending on the client :)), so there's no chance to say "no" to these requirements. :) And you have about 5 days to do it! :) And a lot of the code was written by others and you've never seen it yet! :)

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

It does in almost all cases. But with a lot of extra work! :)

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

I am sorry if I offended you or any other people here with any of my statements. In the same time, please notice my smile signs, because I use them a lot. :)

Vlad