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

?
>
>Speaking hypothetically - my object may be one of a dozen of classes, sharing a few pieces of interface.

You can't share pieces of an interface - you either implement it or you don't....

So I know that any of the candidate classes will have this particular method. They are, however, heirs of the same super-class - for example, I have a bunch of different controls, all of which have a .CastShadow() method, because I wrote one for each. Is there a way to tell dot net to allow using such a method without telling it "this will be one of the following thirteen classes"?

Not sure what you're asking here. In a derived class the methods of the parent, assuming valid scope, are available by definition. If you are referring to dealing with a collection of classes derived from a common parent then sinply cast to that parent - or better, type the collection to the parent in the first place.....
>
>> But more to the point - what have you gained by casting it as object in the first place ?
>
>Exactly. Why do you have to cast (or declare) it at all? Because the compiler will yell if you don't?
>
>My complaint about type-strict compilers is that they force me to do their job.

They force you to provide enough information for them to do their job
OTOH one could argue that dynamic languages force *you* do the job of a strongly typed compiler ?