>>>>>(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 above doesn't seem to indicate that you've actually used interfaces in practical terms. In practice the interface definitions would never be as complex as you postulate. Are you aware, for instance, that interfaces can use multiple inheritance ? But, IAC, I fail to see why the above scenario would require more than one simple 'IHasBackStyle' interface.

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

I don't see any hurdles to using a single class factory in .NET if so inclined - although I can't see a good reason for doing so.

>At the calling side you don't care at all what the type is as long as the accessed properties and methods do exist.

We're back at square one : How *do* you know that they exist?
I don't think your earlier response along the lines of 'because I wrote the code' can be regarded as adequate. What if you didn't write the code (or simply if your memory is not quite as good as you believe) ?

So, in practical terms, you *do* need to establish their existence. But (again in VFP terms) if you want to check that, say, a specific method exists you have to first check for the name then check that it's actually a method rather than an event, or an object, or a property - and you still don't know (or have any way of determining) either the parameters that are supported or the return type. And you have to repeat that for every property/method/event you intend to access on every class instance that comes along.

If I've defined a common interface then all of that is a one line check - after that I can safely use any method, property of event defined by that interface - with intellisense to help and a compiler that won't let me get it wrong. Even better I can use a generic collection and know beyond doubt that every item in the collection implements the same set of members.

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

You think it likely that you will find a third party COM control that uses exactly the same properties and methods as an existing class ?

>>>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.
And see my response....
>
>>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.

That wasn't the context in which I used '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.
>
>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....
Citation ?
..... 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.

I don't think you're telling it things it *should* know. You're telling it things it *needs* to know - but cannot possibly infer...

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

I think this whole subject has been debated before by many. Here's Rick's take from five years ago:http://www.west-wind.com/Weblog/posts/1945.aspx
Anyway with .NET 4 only days away you can now have the best of both worlds in the same environment. I wouldn't go back to VFP unless it had the same options - and that ain't gonna happen :-{