>>
>>How strong do you want it? And, are you sure this is good?
>>
>>In this case, the parameter is an object - that's its type. Now if your smart compiler is too smart, it won't let you pass an object of wrong class (aside the question of how would it know) or of wrong base class. Then you'd have to apply some VB6 inheritance and overload the method for each class to which it may apply. Bad dreams of maintenance.
>
>The advantage of strongly typed parameters is to avoid run-time surprises. Another advantage is execution speed as I see it

Not much in the execution speed, really. Whether the type byte will be in the value block or somewhere with the name of the variable

>Since generics came out, you do not have to necessarily "overload the method for each class to which it may apply"
>
>And if the compiler is too smart as you put it, you can write a method which accepts a parameter of type object. The compiler will cast your type to object prior to calling the method

Sounds better than I thought, then; if you can have both typed and untyped, that's fine. Do the typed most of the time, but when writing general practice code, do generics.

Now... if the compiler will cast anything to object... then it's more or less the same; it will hide my error, if I try to send a date to a method which expects an object, but then it's not an error anymore. If then it has the tools to probe the passed object for existence of properties or members, cool.

My gripe was against strictly-no-choice-must-be-typed languages, not against optionally strongly typed (even if it's on by default). As the old photography buff's adage said, "screw the automatics that you can't turn off".