Data Typing Is A Relic
Written by Ian Elliot   
Friday, 08 February 2013
Article Index
Data Typing Is A Relic
More Than a Hierarchy

More Than a Hierarchy

The principle extends to classes and their objects. There is no problem if you ask for a method that the base object has passed on to a derived object but it fails the other way round.

However objects that are unrelated by inheritance may also have the same method and you could make also safely make the call. The class hierarchy only captures what you can do to objects if you force it to do so - and there is a lot of evidence that this isn't desirable.

Inheritance isn't today thought of as the perfect solution to everything. Inheritance is brittle in the sense that it easily breaks when you try to extend or modify a hierarchy. So much so that many libraries seal their classes for fear that a less skilled programmer will break things.

Today inheritance is thought to be best used sparingly - how often have you heard "prefer containment to inheritance". We have even formalized the interface as an alternative to inheritance because it is a better way of ensuring that an object actually has the properties you are trying to use.

If you think that this argument isn't correct you have to explain why strongly typed class based languages have introduced the interface so that objects can be relied upon to have particular sets of behaviors. Interfaces aren't related to inheritance but to mix-ins where objects acquire blocks of behavior.

You can also tell that there are problems with the whole inheritance hierarchy strong typing approach by the way it needs to be "fixed" by additional mechanism.

For example you have to invent all sorts of ad-hoc mechanisms to allow you to do what you want without breaking strong typing. The C# language is probably the best example of this. We need to introduce delegates to type functions, and then all lambdas to avoid having to explicitly type them. We need generics so that we can avoid writing the same algorithm over and over again for each data type. Even then generics put such a constraint on what is legal that expressing algorithms in a type independent way is very difficult.

So much better to just give up the whole idea of strong typing, the class hierarchy and class-based inheritance.

Put simply you don't need strong typing because it is the main cause of type errors.

Dynamic Objects

If you look to dynamic languages such as Ruby, Python and JavaScript then you start to see that things can be done in a different way. You don't need class and you don't need class-based type hierarchies - even though the pressure to introduce them is great.

Just as there is no real need to complicate matters with primitive data typing there is no need to make objects have a fixed type.

An object is just a bag of properties and it can acquire and lose properties as it runs. Yes objects are better if they are 100% dynamic.

This is where most programmers would despair and claim that this is barbaric and a return to chaos.

On the contrary what has been and is barbaric is they way that strong typing and class hierarchies have imposed unrealistic restrictions on they way code can be reused.

This isn't to say that things are perfect with dynamic type free languages - but this is a relatively new approach. What is really needed more than anything else are better tools to allow the more sophisticated behavior to be kept under control.. The need for good tools isn't a sign that a language has a problem - its a sign that a facility needs to be implemented at design time. It is possible to control the form and function of objects at design time simply by allowing the IDE to perform a property audit. Of course applied simplistically this doesn't pick up compile time errors but then neither does strong typing.

For example in JavaScript you might write something like:

if(math.random()<0.5){
 obj.newMethod=function() {...};
};
obj.newMethod();

Clearly this is only going to work 50% of the time. Strongly typed languages aren't any safer in this respect. Consider:

public class class1{};
public class class2
{
  public void newMethod() { }
}
;

object obj = new class1();
if (R.Next() < 0.5)
{
  obj = new class2();
}
 ((class2)obj).newMethod();

Clearly this too will only work 50% of the time. You can argue that this C# is bad code and no sensible programmer would write it, but this is also true of the JavaScript. The point is that strong typing doesn't save you from runtime type errors either.

The principle that makes type free languages work is often called "duck typing" as a form of insult. Yet the basic principle of if it walks like a duck and quacks then it is a duck is much more sound than having the programmer organize the world into a hierarchy of ducks.

The point is that the world and all the things that we might want to represent within a program do not form a hierarchy but a graph. By dropping strong typing and the class-based type system we can use mix-ins and object containment to build more realistic relationships between objects.

It is time that we tried a different idea.

 

Related Articles

Strong Typing

Type Systems Demystified

Late Binding - Myths and Reality

 

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.

raspberry pi books

 

Comments




or email your comment to: comments@i-programmer.info

 

Banner

 

 



Last Updated ( Saturday, 09 February 2013 )