>>>>>>>>>>You know I respect your opinion and expertise. But I honestly don't get the distaste for strong typing (not limited to you). IMO it protects me from bugs before they happen.
>>>>>>>>>
>>>>>>>>>Yeah, but at the same time you end about half the code for keeping the compiler happy. You also have to buy into all kinds of techniques that are not neccesary in dynamic languages (take ORM, or early binding com interfaces), reflection etc.
>>>>>>>>>
>>>>>>>>>I just don't want to keep telling irrelevant stuff (for me) about the type of variables I'm going to use. If I want to do a SELECT * FROM WhatEverTable, I just wan't to use thaw result without going through casting, typed resultsets etc.
>>>>>>>>>
>>>>>>>>>I want to concentrate on solving a business problem, not concentrate on telling the compiler what it could figure out at runtime.
>>>>>>>>
>>>>>>>>But that's the point. The runtime can't necessarily figure it out.
>>>>>>>
>>>>>>>A dynamic language can. A static typed language cannot.
>>>>>>>
>>>>>>>>The compiler already had its chance and may have let some glaring errors through.
>>>>>>>
>>>>>>>Yeah.... but there technically is not anything that prevents dynamic languages to have type checking at compile time. I think VFP.Net was about that too. If you wish to use static typing for the purpose of catching errors at compile time and performance, you could, but it does not force you into having to use it where it just makes more sense to trust the developer on getting the types right and only raise an error at runtime if its not.
>>>>>>
>>>>>>No, nothing prevents it. Some languages do that kind of error checking, some don't.
>>>>>>
>>>>>>I don't always get the types right. Maybe you are a better developer than me.
>>>>>
>>>>>Thats exactly my point, After having programmed in C/C++, Pascal, all strict typed languages, FoxPro and VFP were such a relief.... no silly error messages anymore because I got the type wrong. No jumping through hoops like using virtual classed to keep the compiler happy. And more recently a lot less needing certain design patterns to work arround type checking.
>>>>>
>>>>>I've got a question for you, maybe you can answer it for me.
>>>>>How do you handle late binding to COM objects? for example: If you want to open any version (> version office 96) of MS word to do a mailmerge, do you still have to work extensively with casting?
>>>>>
>>>>>How would you compare using late bound COM objects in strict typed languages compared to dynamic typed languages.
>>>>>
>>>>
>>>>I have no expertise with late bound COM objects. Sorry.
>>>>
>>>>This phrase intrigued me in your reply: "no silly error messages anymore because I got the type wrong." Uh, would you rather not know? Or you really, really enjoy debugging runtime errors? <g>
>>>
>>>No I do not, but not every type issue results in an error.
>>>the problem is not so much with basic types like integers and characters, but more with class types.
>>>
>>>Since the compiler insists on knowing the class types, you always have to make sure that you declare or cast it to the right class type or its parentclass. And this is a PITA in many cases. I'm sure you used to have a factory in VFP, that can be written in code with lets say 30 lines of code and a metadata table, very straightforward. In strict typed language this can become awfully complicated as at every step you need to tell the compiler the type of object you are creating. In VFP you just do a
>>>

oObject = CREATEOBJECT(cMyClass)

>>>and really be done with it. Further in your code you can access each and every property and method YOU know should be there without having to go through hoops of giving the compiler means of checking it will always be there.
>
>>I'm not really following your logic on this. In .NET you could equally do:

>>object oObject = new cMyClass();

and, since you postulate later knowing what methods are available that implies that you know the actual class so what's wrong with something like:

int i = ((cMyClass)oObject).MyInt;

? But more to the point - what have you gained by casting it as object in the first place ?
>
>yes, but you imply that I know what class it is. Take for example a TextBox, EditBox, Combobox, CheckBox. They all have Top, Left, Width, Height properties. So if I want to rearrange all objects on a form I don't give a hoot about its type (class), I just iterate through a collection and move and resize the objects on the form.
>
>That is just a simple example, but it has far consequences:
>

oWord = CREATEOBJECT("Word.Application")

>I know that oWord now contains a reference to an instance of MS word. I don't know, however which version of word. Whether it is ms word 6 or ms word 2007. I don't give a hoot. I, as a developer know, that oWord will contain certain properties and methods which are common in all versions, and I can access them without having to cast it into anything.
>
>If I want to add an object to a form, and that object has been created through a factory, I don't know at forehand (in code) what this object is going to be typed. so in VFP you'd have something like:
>
>(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 ?

> This is the reason virtual classes and virtual methods exist.
No virtual classes in .NET - maybe you're thinking of abstract?

You'll have to bend everyhting into making the compiler happy because it wants to know all at compile time.

But, in the above, aren't you contradicting yourself?
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.

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.
Best,
Viv