If you haven't checked out the article - "More on Generics in the CLR" in the october edition of the MSDN mag then do it now. It is a continuition of the article Introducing Generics in the CLR of the september issue...
I liked the way Jason Clark explains on 'How Does the Compiler Handle Generic Types' ! I was actually waiting to ask someone about how generic types are handled at compile time, because i was unable to understand the logic for handling type safety during compile time. But thou article has enlightened me :)
I also had this itch on whether the logic inside a generic type can be generic as such ! What i mean is that, say i have a generic collection which needs to have a specific algorithm to handle different types... Now if the whole notion of generics helps in avoid casting, then how is the developer of the collection to write a logic to vary according to the type of the child without casting and finding out the type ?!
Aha ! Now after reading the article, the funda behind constraints perfectly makes sense.. The way i see the constraints given by Jason is that each 'where' clause will be expanded into a 'is' clause during JIT when the actual call needs to be done.
where T : IComparable
Now this means that during JIT, the statement will be considered an equivalent of
if(T is IComparable)
Really cool right .. The implementation of constraints was absolutely necessary to avoid runtime unexpected errors which can be easily resolved at compile time.
But oh well it shows that algorithms cannot be generic unless the super type is the same.. The design of object model now takes primary importance because marker interfaces will now help to identify common types that can have the same algorithm .. Kewl anyway ;)