callable objects ?

David Bruant bruant.d at gmail.com
Wed Apr 18 02:56:57 PDT 2012


Le 17/04/2012 22:44, Brendan Eich a écrit :
> 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: 
>>> http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#post
>>
>> 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).
>
> (...)
>
> This also simplifies direct proxies by allowing any proxy to have call 
> and construct traps.
Speaking of proxies and private names, how would the 2 private name 
interact with the proxies? It seems that it would be poorly because of 
the "private-names-can-be-revealed-as-property-names-in-traps" rule.
Is it time to consider unique names? Since @call and @construct would be 
available to anyone, they are not much that private anyway.


> 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 15.2.4.2 "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.
This was a strong concern and the solution is satisfying as far as I'm 
concerned.

David


More information about the es-discuss mailing list