toString of anonymous function
# Allen Wirfs-Brock (16 years ago)
There has been a lot of discussion of Function.prototype.toString on this and the es5-discuss lists. Basically we didn't reach any consensus on what it should do so there was no change for ES5. The subject can be reopened for ES Harmony.
# Mark S. Miller (16 years ago)
On Fri, Aug 28, 2009 at 8:35 AM, Allen Wirfs-Brock<Allen.Wirfs-Brock at microsoft.com> wrote:
There has been a lot of discussion of Function.prototype.toString on this and the es5-discuss lists. Basically we didn't reach any consensus on what it should do so there was no change for ES5. The subject can be reopened for ES Harmony.
Already is: strawman:function_to_string
The text in 15.3.4.2 Function.prototype.toString () says:
"An implementation-dependent representation of the function is returned. This representation has the syntax of a FunctionDeclaration"
Is there a reason this is a FunctionDeclaration rather than a FunctionExpression? In particular what is the expected behavior for toString of an anonymous function?
var f = function() {} f.toString()
In the engines I tried this gave a result like
"function () {}"
with only whitespace differences. This doesn't match the FunctionDeclaration production due to the lack of an identifier. Whilst the engine could invent an identifier, I don't see what the advantage would be and I would be worried about breaking existing code by doing so. Instead, I think it would be nice to align the spec with reality here.
The text in 15.3.4.2 Function.prototype.toString () says: "An implementation-dependent representation of the function is returned. This representation has the syntax of a FunctionDeclaration" Is there a reason this is a FunctionDeclaration rather than a FunctionExpression? In particular what is the expected behavior for toString of an anonymous function? var f = function() {} f.toString() In the engines I tried this gave a result like "function () {}" with only whitespace differences. This doesn't match the FunctionDeclaration production due to the lack of an identifier. Whilst the engine could invent an identifier, I don't see what the advantage would be and I would be worried about breaking existing code by doing so. Instead, I think it would be nice to align the spec with reality here.