|Written by Ian Elliot|
|Thursday, 05 March 2015|
Page 1 of 3
There is a newer version of the draft of the book here.
As long as you accept the fact that strong typing and hierarchical typing is only about determining what properties are safe to use then we can proceed.
It is true that type checking will detect errors, but the ones that it will detect are fairly easy to find by examining the source code without type checking.
Type checking answers the question
where, for the sake of simplicity, property will also include methods which are just properties that happen to be Function objects. (Refer back to The Function Object if you are not comfortable with this)
If the object instance that o references is known at compile time then you can just look at the definition of the object and see if it has a property p.
If the object instance that o references is not known at compile time then you have to wait and see and risk a runtime error. This is true even if the language you are using is strongly typed.
Beginners often think that constructor and instanceOf are the solution to the type problem - but they aren't they are just a different type of problem.
What Is Type?
In short, if an object has a property p how many ways are there it could have acquired it?
There are four general ways:
If you define a literal object then there is usually only one of them. If you want to create more than one then it is obvious that you should use a constructor or an object factory.
So finding out what properties a literal object has is a one-off task.
That is, it is a unique singleton object in your program and it should have a clearly defined set of properties.
Dynamic properties, that is adding or removing a property at runtime, is much more problematic and in fact it is so messy that it is best treated as a variation on the other ways of dealing with the type problem.
Note: delete does not delete variables only properties.
If you are trying to characterize the properties an object can be expected to have then you really have to ban dynamic ad hoc properties and the delete operator. In practice, we don't really have to ban dynamic ad-hoc properties because these merely add to the properties you can expect an object to have - the real problem is the delete operator. Fortunately this is rarely used.
Before we move on to focus on the constructor and prototype we need to take a moment to look at how prototype inheritance compares and contrasts with class based inheritance.
What this means is that every object has a prototype chain of other objects which are used to supply properties not defined on the original object.
Every object has either null or null and Object in their prototype chain. It is quite easy to construct a prototype hierarchy that looks very much like a class based type hierarchy.
For example you could have an animal object, a dog object and a cat object and the following prototype hierarchy:
What this means is that both dog and cat have animal and Object as their prototype chain.
Notice that this is an object hierarchy not a class hierarchy. What this means is that each entity is an object. The animal object that is in dog and cat's prototype chain is the same object.
This means that the animal object provides all of its properties to both dog and cat. This sounds very restrictive and suggests that dog and cat are some how sharing variables - they aren't. In fact the way this works is very similar to a class hierarchy.
Suppose the animal object has a size property giving the size of the animal then this simply sets the initial value of size for both dog and cat. As soon as dog or cat assigns their own value to size they get their own property.
That is dog and cat share the initial values of all properties as provided by animal. Notice that unless dog and cat override any functions they inherit animal provides the code and this is efficient.
There are a number of differences between this and a class hierarchy.
Perhaps the most telling difference is the lack of an invariable name associated with an object. In a class based language you can define an Animal class and use this to stamp out lots of different instances and you would call these instances of Animal. You think of them as all being the same type of "thing". In a non-class language objects don't have this sort of "type" identity and they don't form natural groups.
|Last Updated ( Sunday, 10 May 2015 )|