title: Implications of Typification in a programming language
body: <p>I have been undergoing a C# course, and the following topic has been popping up in my mind, and time has come, hopefully, to get rid of it: what are the implications of Typification in a programming language?</p>
  
  <p>When I ask myself, what are the reasons/motifs behind the will to build a type-safe language, the ultimate answer (perhaps the only one) I come up with is: the ability to define types in a language allows us to enforce compile-time constraints on the data we use in our program, so that the IDE/compiler can aid as in preventing/detecting errors that otherwise we would miss - and probably figure out only much later - which is of course a problem. Amongst these errors are invalid operations, invalid member access, etc.</p>
  
  <p>If I am right till this point, I then ask: what does it mean/really happens with casting, in languages such as C#? Say I have a method that is defined taking a parameter of type Object, and I pass it any derivation of the type (i.e. any type) - what is happening at this point, behind the scenes?</p>
  
  <p>I am prone to assume that typing also offers me restrictions on which members can I access in any given object instance. In other words, I assume that the compiler always looks at the type of the variable rather than the instance it receives to perform/apply its validation rules and then fire or not an error message. Is this right? In the example I gave below, since the variable type is Object, the compiler will not allow me to access any of my instance members - unless I perform a cast to the type of the instance. The point I want to clarify here is that the instance was and will always retain its type - regardless of whether a cast is being performed or not. The cast, following my theory, is necessary only so the compiler - a tool that is there to aid us in our work - and to which endorsement we are subdued in each step of our building our program - can accept that this code is really a 100% trustful/"secure". </p>
  
  <p>I then think of the aforementioned applied to polymorphism, and seems to make sense: a more general type holding an instance of a more specialized type does not result in a compiler error, because there is no risk in accessing an instance member that is not defined in the more general type, since the more specialized one inherits them all (overriding them or not, or even hiding them). The other way around, on the other hand (when the type is more specialized then the instance) - consists in a problem, since the programmer could very well mistakenly access a specialized member in the instance (which will not exist).</p>
  
  <p>As a last note, I imagine that every instance allocates a block of memory (I wonder if necessarily contiguous or not) - that totals, in size, the sum of each of its type members memory requirements (plus some more metadata/header information, whatever) - and that every member definition generates a specific memory address to be used when accessing an instance to access any given member (be it a variable, a method, etc).</p>
  
  <p>Are any of the assumptions above wrong?
  (Or perhaps I should ask... are any of them right? :)</p>