Thomas,

Wow, you guys are brutal <g>. I'm getting beaten up from all over the world <g>.

>
Are you sure about strong typing being a prerequisite (and what is your definition of strong typing in/for that context <g>) ?
>

Absolutely. Strong typing in this context refers to design-time specification of all types. Genericity, by definition, would eventually require actual types, as distinct from formal types:

class
   COLLECTION[G]
end

class
   COMMAND
end

would eventually come together in the following way:

list_of_commands: COLLECTION[COMMAND]

As for strong typing being a prerequisite to multiple inheritance...Multiple inheritance breaks down when you move into certain esoteric realms of design (most of which can be avoided by rethinking the design), even in Eiffel, which offers semantics features that allow for the handling of multiple inheritance. The disambiguation of method calls necessary in multiply-inherited designs would be virtually impossible without strong typing.

>
Python for instance has multiple inheritance, is dynamically typed, but every variable is an object and on that count alone strongly typed.
>

Dynamic typing is not synonymous with weak typing. Even Eiffel, through conditional assignment, can dynamically type. And, of course, there's always precomputed polymorphism, which provides dynamic typing in a strongly typed language.

>
Since Python reassignes names, the whole thing cannot be equated to python using "variants", but the results are quite similar. I am not sure that a multiple inheritance similar to python is made impossible by vfp's variable characteristics - I think it was a conscious decision only to implement single inheritance.
>

I'm not familiar with Python, and I would agree with you: Single inheritance was probably a conscious decision. I have come to the conclusion after much programming in C++, that the _only_ language capable of handling multiple inheritance is Eiffel. Mr. Meyer designed the language that way from the ground up, and included features in the language for managing it well. With C++, the ability to overload and the inability to rename an inherited class member make it problematic at best. With the OOP model currently implemented in VFP, there is no way VFP could do it, nor should anyone expect it to. Nevertheless, I'm stuck with having to use various other compositing techniques and suffering a bit of repetition that invariably arises in singly-inherited designs.

>
Python has free functions, which are first rate objects as well to be (re-)assigned by code. The "everything has to be a class" rule is something I pesonally don't like in java, since it gives birth to static classes only used as function library replacements.
>

Ah, but if you look closely enough, you'll see that all of those functions could be reorganized into classes. Everything _can_ be classified, even if loosely. It blows my mind that I can't do this in VFP out of the box:

   window_caption: STRING

   window_caption = 'Some Caption'

   window_caption.capitalize
   window_caption.format.underline(4, 9)
   window_caption.format.make_bold
   ...

I know I can achieve this by simply designing a class called STRING and bringing all of the related VFP free functions under the roof of STRING. But what a drag. This should be done already. It's unsettling that ADDOBJECT(), Object.AddObject, and ADD OBJECT can exist side by side in a single language.

I realize that VFP is xBase, but I think that VFP could benefit from a formal rethinking of how object orientation should be grafted onto the language, much like Stroustrup did for us with C. I mean, what's wrong with xBase++ or xBase#?

Eric