Vlad,

D'accord.

regards,

Jim

>It's all like in real life: we have words for objects. Each word is a class. The actual objects are not words, they simply are what they are. When we can identify the word for an object, we know some characteristics of that object. For ex., knowing that an object is a Ford, we know that it has a small "Ford" label on the back, etc. We also know that a Ford is a car and this tells us that a Ford has all the characteristics of a car. So, a Ford is derived from Car. It's true that the "Ford" word makes a reference to "Car", but a Ford object doesn't have this reference. It simply is a Car.
>
>The difference between classes and objects is important because their models are different. Classes are concepts, objects are objects :). It's true that in a specific language implementation, objects of the same class can make references to a common memory area that keeps information about their class (especially for method invocation). In particular, each class may keep reference(s) to its base class(es). But this is not mandatory and each object may have its own private memory area for everything it needs.
>
>So, when we derive A, C, D, E, and F classes from B, we save the code that is reused from B at development time. At runtime, if we instantiate an object from each of these classes, each object will occupy the memory space for a B + the memory space for what was added in the derived class. These objects do not share the memory space for B. The only thing they can share is B's method invocation table. But I don't know how is this implemented in VFP, so...
>
>Vlad