callable objects ?

Brendan Eich brendan at
Tue Apr 17 13:44:43 PDT 2012

Brendan Eich wrote:
> Irakli Gozalishvili wrote:
>> It would be amazing to have clojure like protocols in JS  even 
>> without `IFn`. I think it's very good feet and very useful in JS 
>> where each library has it's own flavored API. I wrote more about it 
>> here: 
> Still hoping Mark will weigh in.

Ok, I talked to Mark and Tom Van Cutsem, and they see no problem 
provided we prevent overriding built-in [[Call]] and [[Construct]] on 
function objects.

Let there be private names @call and @construct (I'll spell them this 
way to avoid tedious imports of const bindings from "@std" or another 
built-in module).

Let Clause 15.3.5 include new non-configurable, non-writable properties 
of function objects named by @call and @construct (built-in functions 
have only @call). The values are built-in and need a bit more thought 
than I can spare now, but see below: @call's value is close to the 
original value of, and @construct's value is 
straightforward enough I think.

Change 11.2.2 "The new Operator" to use @construct not [[Construct]], 
passing the /argList// spread as actual positional parameters: (...argList).

Change 11.2.3 "Function Calls" to use @call not [[Call]], passing the 
/thisValue/ and /argList/ according to the 
convention: (thisValue, ...argList).

Change 11.4.3 "The typeof Operator", the table row with "Object (native 
or host and does implement [[Call]])" in column 1, to test not for 
[[Call]] and *not* for @call, rather to test [[NativeBrand]] === 
"Function" (see ES6 draft "Object.prototype.toString ( )").

This last point is important: we do not want an object's typeof-type to 
change by giving it a @call property. But we do want to enable call and 
construct protocols to be built by users, by giving objects @call and 
@construct properties.

This also simplifies direct proxies by allowing any proxy to have call 
and construct traps.

Comments welcome.


More information about the es-discuss mailing list