callee
is a property of the arguments
object. It can be used to refer to the currently executing function inside the function body of that function. This is useful when the name of the function is unknown, such as within a function expression with no name (also called "anonymous functions").
(The text below is largely adapted from a Stack Overflow answer by olliej)
Early versions of JavaScript did not allow named function expressions, and for this reason you could not make a recursive function expression.
For example, this syntax worked:
function factorial(n) {
return n <= 1 ? 1 : factorial(n - 1) * n;
}
[1, 2, 3, 4, 5].map(factorial);
but:
[1, 2, 3, 4, 5].map(function (n) {
return n <= 1 ? 1 : (n - 1) * n;
});
did not. To get around this arguments.callee
was added so you could do
[1, 2, 3, 4, 5].map(function (n) {
return n <= 1 ? 1 : arguments.callee(n - 1) * n;
});
However, the design of arguments.callee
has multiple issues. The first problem is that the recursive call will get a different this
value. For example:
const global = this;
const sillyFunction = function (recursed) {
if (this !== global) {
console.log("This is:", this);
} else {
console.log("This is the global");
}
if (!recursed) {
return arguments.callee(true);
}
};
sillyFunction();
In addition, references to arguments.callee
make inlining and tail recursion impossible in the general case. (You can achieve it in select cases through tracing, etc., but even the best code is suboptimal due to checks that would not otherwise be necessary.)
ECMAScript 3 resolved these issues by allowing named function expressions. For example:
[1, 2, 3, 4, 5].map(function factorial(n) {
return n <= 1 ? 1 : factorial(n - 1) * n;
});
This has numerous benefits:
- the function can be called like any other from inside your code
- it does not create a variable in the outer scope (except for IE 8 and below)
- it has better performance than accessing the arguments object
Strict mode has banned other properties that leak stack information, like the caller
property of functions. This is because looking at the call stack has one single major effect: it makes a large number of optimizations impossible, or much more difficult. For example, if you cannot guarantee that a function f
will not call an unknown function, it is not possible to inline f
.
function f(a, b, c, d, e) {
return a ? b * c : d * e;
}
If the JavaScript interpreter cannot guarantee that all the provided arguments are numbers at the point that the call is made, it needs to either insert checks for all the arguments before the inlined code, or it cannot inline the function. This means any call site that may have been trivially inlinable accumulates a large number of guards. Now in this particular case a smart interpreter should be able to rearrange the checks to be more optimal and not check any values that would not be used. However in many cases that's just not possible and therefore it becomes impossible to inline.