|Thursday, 23 September 2010|
Page 1 of 3
What use is type?
The first thing to get straight is why we worry about typing at all. The most primitive notion of type in programming comes from "data type". Clearly what you can do to an item of raw basic data depends on what it is. That is you can add numbers together but you can't add words. To stop programmers from making silly mistakes data has to have a type that determines what operations are valid - or does it?
There are two ways you can avoid having to introduce data typing. The first is that you can modify the meaning of an operator to suit the data - the add operator is arithmetic on numerical data and concatenation on textual data. The second is that you can do your best to make the operation work by manipulating the data. For example:
displays 12 as the numeric 1 is first converted to a string. Not so good for programmers expecting the conversion to go the other way and the result being 3 - but it works. Notice that in this case it makes sense because you can always concatenate two strings but you can't always numerically add two strings.
The point is - you are not forced to explicitly recognise the differences in types of data as long as you allow operators to change what they do according to the data.
It is mostly a matter of attitude.
Objects, class and type
The whole idea of type becomes more complicated and sophisticated as soon as you allow objects to be part of a language. An object has data and methods thus its type in the original sense is "mixed". For example an object that has properties that are strings and numbers clearly isn't either fundamental type. If you want to extend the type idea to include objects then you really have to regard every object as defining a new type. But here we hit our first subtly.
Is type defined by object or by class?
In a class oriented language you define a class, e.g. MyClass, and then use it to create as many instances of the class as you like MyObject1, MyObject2 and so on. As each of the instances is guaranteed to have the same methods and properties then it is reasonably to consider them as instances of the same type.
What this means is that in a class based language class can be considered to define type and all instances of the same class are instanced of the same type.
However things are a little more complicated because of the possibility of using inheritance. Class based languages usually allow you to create a new class that inherits from an existing class. For example:
MyClassB inherits MyClassA
What this means is that the definition of MyClassB starts off with all of the properties and methods that are in MyClassA. If you do nothing more and use MyClassB to create instances you can see that it is reasonable to consider MyClassB to be the same type as MyClassA.
However inheritance allows the extension of existing classes. That is, MyClassB can have methods and properties added to it. MyClassB can be "bigger" than MyClassA. What this means is that anywhere you could use MyClassA you can also use MyClassB, but not the other way around. You can see that MyClassA could be regarded as a subtype of MyClassB.
Hence in a class based language that allows inheritance it is natural to think of type as being hierarchical - and this is indeed the way that it is implemented in most other typed object oriented language.
This the neat and tidy picture that languages like Java and C# would like to make the defacto standard but class based typing brings with it one huge problem.
Suppose you want to allow dynamic features. That is, suppose you want to include in the language the ability to add properties and methods to an object. Then you have to answer the question - if I add a new method at run time to an instance of MyClassA is it still of type MyClassA?
The obvious answer is no, it's a super-type of MyClassA - but this isn't the only possible answer.
Now consider what happens if you allow an instance to remove properties or methods. Now we have a MyClassA instance which is a sub-type of MyClassA.
You can see that it gets very complicated.
you would use
and to add it back again:
|Last Updated ( Monday, 04 October 2010 )|