The whole concept of type in Javascript is a little artificial but it is undeniably useful. What is important is not to try to see it in terms of the more common strongly typed languages. Javascript isn't typed, it doesn't implement type, it doesn't use type and it doesn't enforce type. But if you want type - you can have it!

Javascript isn't even duck-typed it simply tries to ignore type as much as possible by taking the remarkably egalitarian attitude that (nearly) everything is an object.

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:

alert(1+"2");

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.

Now to turn to Javascript.

Javascript objects and type

Javascript doesn't use classes to define objects - it simply lets you create instances by adding methods and properties to an object. As such it can't implement a class based type system.

What is more, Javascript objects can be added to at runtime creating augmented objects. You can also remove properties from objects at run time, although this is rarely used. For example to remove the z property from:

point={x:0,y:0,z:0};

you would use

delete point.z;

and to add it back again:

point.z=1;

You can see that in Javascript objects are completely dynamic and this makes the very idea of type seem hardly worth inventing and certainly not worth using unless as part of a package of self imposed restrictions on how an object is treated.

In Javascript an object does not have an invariable type.

However, Javascript does implement a type system of sorts and it's not what you would expect if you have a background in a class based language.

<ASIN:0596517742>

<ASIN:0470526912>

<ASIN:1590597273>