Why can't objects be callable?

Brendan Eich brendan at mozilla.org
Wed Mar 7 09:16:53 PST 2012


Russell Leggett wrote:
>     import {apply,unapply} from "@extractor";
>     const Twice = {
>         [apply]:function(x){
>             return x * 2;
>         },

This would have made pre-Proxies Narcissus a piece of cake. Instead I 
had to extend SpiderMonkey (__call__, __construct__, etc. -- 
unstratified meta-methods a la Python).

Anyway, there's no deep reason other than (typeof x == "function") <=> 
(x is callable) for a native (not host) object x. I didn't have time to 
put callability into the base language in the first ten days, and no one 
was motivated to do so for ES1. After that it was off the agenda.

Optimizing implementations, secure program analyses, and other "readers" 
might object to losing the (typeof x == "function") <=> (x is callable) 
invariant, but it doesn't help in practice due to host objects. JS 
engines already must optimize based on built-in and/or inferred type, 
hidden class, etc., and many super-optimizefunction calls (inline, 
specialize by argument types and values). Host objects require special 
handling (de-optimization or separate-from-function optimization if 
worthwhile).

With direct proxies we have an incremental solution for ES6. I don't see 
a for-all-objects base-level approach that uses hidden names passing 
into ES6 at this point. Doing it later is even less helpful. But worth 
discussing -- the need to create a direct proxy or function in advance 
of needing some (other) object to be callable does get in the way sometimes.

/be


More information about the es-discuss mailing list