>>>>>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.
>>
>>I think this is the crux of our disagreement. Give me reduced chances of runtime errors (nearly) every time.
>
>Yeah, I think so... I'm more of a "Get me ultimate flexibility and I'll deal with those pesky run time errors" guy.
>
>>>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.
>>
>>I don't think that is neccessarily a dynamic v. typed issue - using a data store to supply a class factory is an option in either case.
>
>Of course you can do everything in a strict typed what you can do in a dynamic typed language, but writing a database application in assembly does not make an awful lot of sense. I guess what I'm saying there is application to dynamic typed languages. Whether it is your piece of cake is something entirely different.

Don't think you can regard Assembler as being strongly typed since the only type it's got is byte :-}

>
>It is just a shame that, how fast some things develop, the two camp don't seem to grow towards eachother fast enough. Why the hell can't you have the best of two worlds. Sure, C# now has some support for dynamic types, but it is not enough.

TBH, I haven't even played with .NET4 properly yet - but in what way is it 'not enough' I'd think once you open that particular Pandora's box there aren't any real restrictions left.......

>ORM is still a problem and the current technology does not seem to be stabilized. Each year new ORM techniques are released, which are better than the previous, but still is not there yet. OTOH, there is no reason why dynamically typed languages could not get more features from for example .NET. Declaration of variable and checking upon them to catch typing mistakes, should be possible for both camps at design time, thus when writing the code (compile time is too late, IMO). As you know when declaring variables, VFP could also use intellisense to look into com objects, but this could be improved as well. Ideally both camps grow entirely toward eachother and you can use both approaches in the same language.

No argument about ORM implementations. I'm using EF at the moment - definitely a love/hate relationship :-}
And yes - if VFP required that variables be declared then intellisense could catch a lot of typo's

>
>>>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.
>>
>>I'm still curious to know where you came across the need for so many interface definitions. A good design should handle most of these problems via class inheritance. Look at the .NET framework. I don't think you'll find many classes there that implement more than, say, three interfaces. I really don't see the big deal.
>
>Errr. that is something I've tried to explain. Take for example the discussion about "Backstyle" property for GUI controls. You proposed to add a simple "IHasBackstyle" interface to it. O.k. next time its not the Backstyle property but the readonly property. Do you want to add a "lHasReadonly" interface to all the controls that do apply? Where does it stop? This also has implication on planning the development of your application. You have to think about this stuff carefully in advance or things become a real mess. In dynamic languages, it is much more straightforward to add such functionality in during the course of such a project.
>

I can only repeat that I have never, in the real world, come across cases where such complex usage of Interfaces is needed. In the vase majority of cases the design of the class hierarchy does the job. But OK - if you really don't like using interfaces then as in Dragan's example, you can fall back on reflection but then (as in VFP) it will be far less efficient.

>>>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
>>
>>Top of my head I can't see much use for this pattern in .NET. Firstly all classes must supply the same callback method before they can play ball so you still effectively force it to implement a specific interface. But, IAC, I don't see anything there that would not be handled in a simpler and more flexible way using extension methods. Maybe I missed something tho....
>
>I really depends on what you want to do I guess. Again I'm not a .NET programmer, but the idea behind the visitor pattern makes sense. You might not want to bloat all your classes with additional functionality, but leave it to visitor classes. I know, there are other ways in other languages to resolve this, but that does not dismiss the viability of this pattern.
>
>>>"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'.
>
>>Still the same argument : If you rely on an expectation of the interface being present (and your code fails if your expectation fails) then why not insist on it's presence ? And how do you know that you have the correct parameter list for SendMail() ?
>
>I don't, but really, that is up to me as a developer. I have absolutely no problems with that.
>
>>>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.
>
>>I just don't accept the correlation you make between 4GLs and strong typing. The definition of one doesn't depend on the other
>
>Again, you're reading too much into it. Most dynamic languages, you'll find in the 4GL arena. 3GL is typically the domain of strict typed language. Whether a 4GL can be a strict typed language is beyond the discussion here.
>
>>>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."
>
>>That page makes no secret of the fact that it reflects varying opinions. You picked one. It also says:
>>Some of the factors which writers have qualified as "strong typing" include:
>>The absence of ways to evade the type system
>>Omission of implicit type conversion
>>Disallowing any kind of type conversion
>
>That page also says: Most generally, "strong typing" implies that the programming language places severe restrictions on the intermixing that is permitted to occur, preventing the compiling or running of source code which uses data in what is considered to be an invalid way. For instance, an integer division operation may not be used upon strings; a procedure which operates upon linked lists may not be used upon numbers. However, the nature and strength of these restrictions is highly variable.
>
>And I stick to that "most" general definition. By this definition VFP is strongly typed, and C/C++ are more (arguably) more weakly typed (http://en.wikipedia.org/wiki/Weak_typing)

Could argue some more but, TBH, I'm a bit debated-out (and need to do some real work :-} )
Best,
Viv