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

To me they are pretty strong arguments, but that really depends on how you like to develop your application. I like flexibility, even if it comes at the cost that it highers the risk of running into a runtime error. After all, this might be able to resolve that without creating a new exe that has to be redistributed and installed at a client. Just disabling the faulty class and check in the new class or compatible class.

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

Strict typing could avoid a lot of runtime errors, but certainly not all. The fact is that in both cases you need to test your code.

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

I'm not a .NET programmer, but I do have quite some experience in multiple inheritance in C++. there is a lot of similarity between them.I certainly know what they are and what they are used for. The problem with this approach that depending on your needs you need a lot of interfaces on each class depending the operations you might to perform on those objects. For each new operation you might need in the future you might need to create a new interface because some methods or properties which some objects share are not shared by a single interface. This is not the way to go anyways. The best way to resolve this problem is by the visitors design pattern, most likely with a double dispatch to workarround the typing issues (you can google on that one). The other way arround your classes become so bloated.

The visitor design pattern is one that is hugely simplified in dynamic languages as the double dispatch is not necessary at all.
See http://en.wikipedia.org/wiki/Double_dispatch
http://en.wikipedia.org/wiki/Visitor_pattern

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

Nicer and better Gui, without the quircks of the old one?

>And it you are intending to use the differences then your common code base is already out of the window......

Depends, if this is part of a upgrade, you can replace them with a single change in the meta data, and begin taking advantage of the new one. It could have an adapter design pattern to make the translation between the old and new interface. Which really can work both ways. We have had a couple of examples internally where we wanted to change classes, from email intergration to picture controls to specialised command buttons.

But really that is not the issue here. Whether something is usefull or not is really up to the programmer, refuting the usabillity of this point does not refute the point.

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

"Personal recollection"? no. If I do a

oClient = oFactory.MakeObject("EmailClient")
oClient.SendMail("Me@home.nl", cSendTo, cCC, cMessage, cAttachments, lShowDialog)

I would expect every object that possibly comes down the Factory in the code above to have the same 'interface'.

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

You're reading too much into it. 4GL language are specifically designed to take care of trivial stuff and let you concentrate on solving the problem, much less on the actual implementation. so it provide a language that takes care of most common problems and time wasters. Probably the 1st 4GL was SQL, because it lets you describe what data you want to retrieve, but don't care (so much), on how the resultset was obtained. Compare that to the C/C++, Pascal, and even the XBase record oriented commands. They give you greater control, but you have to do a lot more programming to get to the same result as a SQL command. Form designers, report designers are also examples of 4GL because they get rid of hand coding forms and reports.

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

http://en.wikipedia.org/wiki/Strongly_typed_programming_language
"The object-oriented programming languages Smalltalk, Ruby, Python and Self are all "strongly typed" in the sense that typing errors are prevented at runtime, but these languages make no use of static type checking: the compiler does not check or enforce type constraint rules. The term duck typing is now used to describe the dynamic typing paradigm used by the languages in this group."

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

Me too.