If you call Object.prototype.toString.call(anything)
the result is always [object Something]
, where Something
could be one of several
Annex F of the ES5.1 specification says this about Object.prototype.toString
:
15.2.4.2: Edition 5 handling of undefined and null as this value caused existing code to fail. Specification modified to maintain compatibility with such code. New steps 1 and 2 added to the algorithm.
This is a correction that was made in the ES5.1 spec. Prior to ES5, passing null or undefined to toString always caused the global object to be passed instead. Strict mode related changes in ES5 cause null and undefined to be passed without modification. As specified in ES5, passing null or undefined to Object.prototype.toString
caused a TypeError exception. This exception broke some existing code so we had to fix the spec to not throw in that case.
So what should toString
return for null and undefined? It turns out that a lot of existing code also expects Object.prototype.toString
to always return a string of the form "[object *]"
. So, we decided to make null and undefined produce "[object Null]"
and "[object Undefined]"
.
This seems to have worked and generally permitted existing ES3-based code to keep working in the presence of the strict mode related changes in ES5/5.1.
Okay, think of it like this:
undefined
and null
are implemented as singleton objects in the interpreter. For example undefined
is actually Undefined.instance
in Rhino (implemented in Java).toString
method defined exposes the class name of the JavaScript value. However since the value is not the class itself but an instance of the class, toString
returns the a string of the form [object ClassName]
.[object *]
form is redundant. However someone wanted it to be like that and so we're stuck with it. Now that it's there it will cause a lot of problems if it's suddenly changed. Old code that depends upon it may break.Edit: It's important to note when JavaScript ends and the interpreter begins. For example when you call a function in JavaScript the interpreter creates a new execution context, which is an object in the language in which the JavaScript interpreter is written (not JavaScript itself).
Similarly, the [[Class]]
of a JavaScript value is the class in the language in which the JavaScript interpreter is written, which is used to create instances of that class. For example, in Rhino functions are instances of the class org.mozilla.javascript.BaseFunction. This class has a method called getClassName
which returns Function
(the [[Class]]
of the instances of BaseFunction
).
Similarly there's a class called org.mozilla.javascript.Undefined which has a static property called instance
which is the singleton instance of Undefined
.
Here is what ES5 says:
15.2.4.2 Object.prototype.toString ( )
When the toString method is called, the following steps are taken:
- If the this value is undefined, return "[object Undefined]".
- If the this value is null, return "[object Null]".
- Let O be the result of calling ToObject passing the this value as the argument.
- Let class be the value of the [[Class]] internal property of O.
- Return the String value that is the result of concatenating the three Strings "[object ", class, and "]".
So toString
first deals with undefined
and null
, then converts the argument to an object, then returns the internal [[Class]]
property of that object. Note that toString
is intended to be inhertied by objects, so it's only fair that it behaves like it does.
In ECMAScript, everything is an object. Primitives are just a convenience to avoid things like:
// Create number objects with the same value
var a = new Number(7);
var b = new Number(7);
a == b; // false
a.valueOf() == b.valueOf(); // true
A primary goal of JavaScript was to be simple. Loose typing makes life easier, but it also means there are some foibles to learn.