Calling toString on function proxy throws TypeError exception

Claude Pache claude.pache at
Tue Oct 27 08:35:43 UTC 2015

> Le 26 oct. 2015 à 20:20, Allen Wirfs-Brock <allen at> a écrit :
>> On Oct 26, 2015, at 11:20 AM, Mark Miller <erights at> wrote:
>> I like the idea a function proxy is more encapsulating of its implementation than a function is.
>> I also like the idea of treating a function proxy as a builtin callable, rather than a function written in JS, and return something like "function () { [function proxy] }" as Tom suggested or "function () { [native code] }" as Claude suggested. We need progress on the draft spec for F.p.toString reform, including the standardized pattern for the function sources that are not supposed to parse, e.g., "function () { [...stuff...] }”.
> I guess I still don’t understand the use case for applying there built-in F.p.toString to any callable.  If you are explicitly defining a callable proxy you may want to define a `toString` method for it that does something that makes sense for the specific kind of callable you are creating. But when you expect to do:
> ```js
>   evalableString =;
> ```
> with the expectation that the result you are going to get will be useful for anything?
> Allen

The expectation is not that `F.p.toString` will always return something useful; it is that, for any callable object, it will return a string and not throw, because it was so since the dawn of JS.

For example, a random programmer may write:

Function.isGenerator = function () {
    return typeof this == "function" && this.toString().match(/^function\s*\*/) != null

That function will work (in the sense of: will return an answer; I'm not judging the quality of that answer) with anything reasonable fed to it (where "reasonable" excludes things like `(class { static toString() { throw "pwnd!" }})`).  Well, ... until a proxy for a function is encountered.


More information about the es-discuss mailing list