>>>>>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 ?
>
>See my comment above: 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
>
>It is not that it CANNOT be done. It just that you'll have to write all of those interfaces just to keep the compiler happy. It does not make sense to me.
>
>>But, IAC, I fail to see why the above scenario would require more than one simple 'IHasBackStyle' interface.
>
>See above
>
>>>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.
>
>To be able to change all kind of classes on a install by install basis? even if they are not contained within the EXE itself. This gives you enormous flexibility. But anyways, if your factory returns an object based on the interface of object (I'd assume that would be the only way to do it), that you still have to cast it into the appropriate class or interface at the calling side. Even if you do it on interface you are exploding the number of interfaces. I doubt even if this strategy would work for third party tools.
>
>>>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?
>
>Two reasons:
>1. I create an object from which I know it will have them because it will have a minimum (logical) interface (not in the .NET context). The program does not know, but I do know. And if I'm wrong the application will generate an error.
>2. I can use functions like GETPEM() and PEMSTATUS() to find out.

You're just repeating the arguments that you used before:
(a) You know they're there because you wrote them and/or
(b) You can always use GetPem() to find out.

I thought I'd made obvious why I saw those options as pretty weak arguments ?

>
>I wouldn't let the program generate an object that would not have the required properties and methods. However at the runtime I have no idea of which class they are
>
>>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) ?
>
>Then the application will generate an error at runtime.

I'd already worked out that that might happen :-}
I was hoping your answer would tell me how you would avoid it.....

>
>>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.
>
>In practical terms, I know because I know which type of object is returned, or I have to check manually with for example GETPEM()

See above.

>
>>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.
>
>yeah, but really here the problem is exactly in the term "common interface". Do you really know anyone that will create an interface for each and every property and method? And again, its just another example of "code to keep the compiler happy"

Can you just confirm that the above is from your experience of implementing interfaces in real world scenarios. To me it sounds otherwise.....

>
>>>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 ?
>
>Have you seen the number of commercial treeviews that are upwards compatible with the MSCOMM treeview? But that is besides the point. This could even apply to subversions of the same control... for example the report viewer of crystal reports. Upgrading from version 7 to 8 to 9 to ... etc.

I didn't say 'upwardly compatable' - I said 'exactly the same'. If you're only going to use the methods and properties of the MSComm version then why use a third party control ? And it you are intending to use the differences then your common code base is already out of the window......
>
>>>Ohhh, but there is the wrinkle... I see much value in doing that, see example of the treeview above.
>>And see my response....
>
>And mine
>
>>>>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'
>
>It wasn't ?

No. I was pointing out that you can't know the properties and methods of a class without knowing the class. If, by 'knowing' you mean that you are happy to rely on personal recollection then so be it....

> The beauty of the .NET compiler is that you'll have a choice on a variable by variable basis. If you want it to be strict typed, then it will the strict typed, otherwise it will be as dynamically typed as in VFP.
>
>>>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 ?
>
>C'mon this is well known stuff. 1 GL, zeros and ones, 2GL assembly, 3GL abstrating away from the processor implementation, 4GL designers, code gerators, languages that more specify what needs to be done as opposed to what. Check the literature.
>
>The higher the number:
>- The less control on efficiency
>- The more you specify of what needs to be done as opposed to how.

I don't follow the logic which seems to be:
(a) Productivity in higher in 4GL languages.
(b) More 4GL languages are dynamically typed.
Therefore productivity is higher in dynamically typed 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.
>
>By telling it the type, its more of how rather than what. you specify on how the variable needs to be interpretated.
>
>>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
>
>I know this blog, however I don't share all his viewpoints here, but I'm doing stuff that takes the best out of dynamic languages every day. Even the title is wrong. VFP is also strong typed.....

VFP strongly typed ? People can argue a lot about the detailed definition of a strongly typed language - but I don't think many people would argue that VFP even begins to fall into that category ......

whereas C++ is regarded weakly typed. The right terms to use are strict typed versus dynamically typed.
>
>I've done my share of C/C++ and pascal in the past and was really irritated by the amount of code that needs to be written to keep the compiler happy. Things certainly have changed somewhat .NET, but still I feel much more comfortable with dynamic languages. I can be very flexible, sometimes too flexible I admit, esspecially with mixing metadata with class creation, validation, DML, etc. Things that are an order of magnitude more work and more difficult to do in strict typed languages.
>
>> 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 :-{
>
>Well, thats what I'm waiting for. Waiting for the DLR to evolve and other dynamic languages to develop.

You know something - I've a sneaking suspicion we're just aren't going to reach an agreement on this stuff? :-}