>>>That is just a simple example, but it has far consequences:
>>>

oWord = CREATEOBJECT("Word.Application")

>>>I know that oWord now contains a reference to an instance of MS word. I don't know, however which version of word. Whether it is ms word 6 or ms word 2007. I don't give a hoot. I, as a developer know, that oWord will contain certain properties and methods which are common in all versions, and I can access them without having to cast it into anything.
>>>
>>>If I want to add an object to a form, and that object has been created through a factory, I don't know at forehand (in code) what this object is going to be typed. so in VFP you'd have something like:
>>>
>>>(just very simplistic, not tested)
>>>
>>>

FUNCTION AddObjectToContainer(cClassKey, oParent, cName)
>>>LOCAL oObject
>>>
>>>oObject = NULL
>>>
>>>IF !USED("MyFactoryClasses") 
>>>   USE MyFactoryClasses IN 0 ORDER ClassKey
>>>ENDIF
>>>
>>>IF SEEK(cClassKey, "MyFactoryClasses")
>>>    oParent.AddObject(cName,  MyFactoryClasses.ActualClass)
>>>    oObject = oParent.&cName
>>>ENDIF
>>>RETURN oObject

>>>
>>>When writing I don't have a clue what oParent is. It could be a form, a grid, a container, a toolbar, _screen. I don't know what type of object has been added to the form etc... I don't care here either.
>>>
>>>The point is however, that in particular cases you don't give a hoot about its type, because YOU AS A PROGRAMMER know that certain properties and methods do exist, and telling the compiler the same might be very difficult.
>>
>>I've never found it difficult. Why do you regard it so ?
>
>Because you don't know the exact type of what has been created, and you do not care either. So how am I going to tell the compiler what type it is?

You may not know the exact type - but you must know the methods and properties that it exposes (the interface). In your class factory example is the factory going to return instances of classes where the exposed properties/methods are inconsistent? If so how are you going to make use of them in any meaningful way ?

>O.k. can you give me a .NET equivalent for the object factory as described above.

I'd simply ensure that all classes returned by a specific call to the object factory implement the same interface. Can't see much point in an object factory that didn't do that.....

>>> This is the reason virtual classes and virtual methods exist.
>>No virtual classes in .NET - maybe you're thinking of abstract?

>My rant is not neccesarily about .NET but more about static typed languages in general. Thinking too much in C/C++ I guess. But thanks for the correction.

>>You'll have to bend everyhting into making the compiler happy because it wants to know all at compile time.
>>But, in the above, aren't you contradicting yourself?
>
>Why?

In essence: If you know the type then you can tell the compiler. If you don't know the type then you can't make assumptions regarding the properties/methods that are exposed. You can't have it both ways :-}

>
>>You use an object factory to create and add objects of an unknown type to a form.
>>You then iterate over the collection of objects perfectly happily accessing the Top, Left, Width and Height properties because you know they exist.
>
>Yeah... and how would you do that in .NET?

The simple answer in this instance , at least for Winforms (since the properties wouldn't apply in WPF or ASP.NET), is that they all derive from the Control class so you could cast to that.

>
>>On the Word example I'd much prefer, where possible, pulling it in as .COM Interop and having the full intellisense at my disposal. But, yes, there is an argument that late binding is sometimes preferable - thus the DLR in .NET4 which will give you what you need.
>
>And DLR stands for........ exactly my point !!

I thought your point was that strongly typed languages were bad. Mine was that they are good - not that dynamic typing has no place at all. That said I know which I'd rather be without :-}