>>>
>>>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".
_
Dragan,

I told you it was different. You ought to read some books and download the express version - just to get the feeling

The rules are - as far as I can see
(1) Strongly typed, eg you cannot do a GoMonth() on something that is not a date
Isn't that a good thing ? Foxpro would blow up at runtime

(2) You can use generics.
- they are still type checked
- they are JIT compiled for each type

(3) The compiler does a cast to object if your method accepts an object (and there's no overload for your type)
But once you have entered the method and 'received' an object, you are responsible for type checking - ie which operations you perform on the object - it can blow up at runtime then

Really Dragan, read something, get yourself some basic experience with c#. I am sure you will like the language, its constructs and many things you can do with it
[ eg define operators on types, pass functions a parameters, define functions on functions.]
It's not been released yet, but the library for parallel processing looks promising
The only limit is one's imagination

So, what are you waiting for ?