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

Because of all the objects created from here, might not share a single interface. they might share some properties and methods, but no necessarily an entire interface. Take for example in VFP where a few controls have a backstyle property and some don't, even though they are controls with the same top, left, width and height properties. If you want to cover all of that you'll have to write an awfull lot of interfaces to cover all possible permutations, possibly ending up writing an interface for individual methods or properties.

The other side effect is that you'll have to write a factory class per interface. In VFP, thats absolutely not neccesary. You could, if you like, write one single factory class that handles all: Adding objects to containers, adding objects to properties or just creating an returning a single unbound object. At the calling side you don't care at all what the type is as long as the accessed properties and methods do exist.

So if all my treeviews are created through a factory, and one day I decide to replace the activeX treeview control with another 3rd party control that has all the same properties and methods I use, all I need to do is to change the metadata of the factory and my app is using another treeview in the app while not changing any piece of sourcecode at all.

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

Ohhh, but there is the wrinkle... I see much value in doing that, see example of the treeview above.

>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 :-}

Yes you can... this is exactly what the VFP compiler for .NET is doing. Giving you a choice, strict typed or dynamic typed. Taking best of both worlds.

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

See above, thats great for this example, but if you were iterating through all objects that have a backstyle (talking from a VFP perspective here) property wanting to set them to transparent, it becomes slightly more difficult, because though all objects might share the control interface, they might all have a backstyle property, so you still have to cast them to their exact type before setting the property. In VFP, you could even use the SetallMethod(), otherwise its just checking the property exists (GetPemStatus)

>>>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 :-}

Of course not, strict typed languages absolutely have their place. But they are no peace meal either, there definately is a place for dynamic languages as well. Most 3GL languages are strict typed, but more 4GL languages are dynamically typed, for a good reason. Productivity generally is higher in 4GL languages as you are less concerned on how, but rather on what needs to be done. In 3GL languages you spend more time in telling the compiler things it should know before the program can be compiled.

And as I said, most design patterns are easier to implement in dynamic languages. Some even are invisible because they are directly supported by the language.