|Written by Nikos Vaggalis|
|Thursday, 18 November 2010|
Page 6 of 6
So far we've talked about value representation not being preserved and found out that a strongly typed language converts implicitly between types when there is no potential for data loss.
For example :
A short fits into an int but the opposite is not true hence the compiler warns us.
By using an explicit cast we effectively tell the compiler that we know that we might lose data but we want to proceed with the operation regardless. But an explicit cast does not only do that; it also changes the type of the underlying value, the binary representation of an integer changed to that of a short
But there are conversions that preserve the representation of the underlying value and just alter the type of the reference variable.
A strongly typed language will allow implicit and explicit conversions between references that are inheritance related (implementation or interface wise).
A classic example is that of Polymorphism. When a method expects an object of the base class and you pass in an object of the child class then an implicit conversion of the reference variable's type is happening. It effectively makes the reference variable point to the base/parent part of the instance without altering the representation of the instance.
Here the reference type of the variable is implicitly converted, not the representation of the actual instance. In other words :
Class1 x = objA;
Still the representation of the value in memory has not changed (it is still a Class2 instance),it just altered the type of the pointer.
But implicitly converting a base class reference to a derived class reference cannot happen:
Class1 objC = new Class2();
Error 1 Cannot implicitly convert type 'ConsoleApplication2.Class1' to 'ConsoleApplication2.Class2'. An explicit conversion exists (are you missing a cast?)
Class2 objD = (Class2)objC; //ok
Strong,weak,static,dynamic what is it all about?
Labelling a language as of a certain type is apparently not that easy since it can incorporate a mixture of type systems; furthermore such a labelling would not offer anything significant.
But knowing the underlying concepts, quirks, weaknesses and strong points of each type system helps in avoiding potential pitfalls (Quoting the Camel book "You will be miserable until you learn the difference between scalar and list context"), leads to less buggy code and allows maximum exploitation of each system's unique features as to increase productivity, flexibility and agility.
It can make it easier to learn a new language which belongs to another system. For example knowing Perl and attempting to learn C#, you can avoid mistakes and inexplicable behavior caused by the variation of the languages' type systems.
It makes it easy to get rapidly acquainted with new features added to a language. For example a Perl programmer will feel right at home when he first encounters the new dynamic type introduced in C# by relying on its dynamic language background.
It can ease the burden of using multiple languages in the same project on an integrated platform like .NET.
Ultimately it can aid in choosing the right tool for the right job and on a subsequent level aiding in using that tool productively and squeezing maximum performance off it.
For example I would use Perl for XML parsing since its dynamic and weak properties make processing XML a breeze, whereas I would use C# and a strongly (in this context strong is shorthand for static and strong) typed dataset for programming against a database.
If you follow the trend closely you will have noticed that we are reaching an era of the fusion of type systems to address each other's, as Perl 6 and C# 4.0 demonstrate. Having a solid grasp on the underlying concepts will help in keeping track and adapting to change smoothly
This short series has gone into detail trying to explain the concepts behind type systems and set the core foundations for further exploration. There are many relevant issues to be investigated, for example learning the rules that a user-defined conversion should follow in order to be valid. Looking at the language specifications and RFCs is always to be recommended:
Representation and Identity by Eric Lippert
or email your comment to: firstname.lastname@example.org
To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin, or sign up for our weekly newsletter.
|Last Updated ( Friday, 09 November 2012 )|