Awesome. That gives you all the building blocks for trying out object exemplars 
via a library.

I would add: [[HasInstance]] -> @hasInstance



On Apr 17, 2012, at 22:44 , Brendan Eich wrote:

> 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).
> 
> 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 
> Function.prototype.call, 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 Function.prototype.call 
> 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 
> 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. 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.
> 
> /be
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
> 

-- 
Dr. Axel Rauschmayer
[email protected]

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to