Hi Tom,
The idea here is that it's "obj" that's the proxy/promise.
For example:
var pet = future();
var closure = function(){
return pet instanceof Cat;
};
resolve(pet); // later
closure(); //?
I should've clarified that it's the [Prototype] of pet that needs to be
delayed. Not prototype of Cat. It may be resolved to any number of different
prototype chains depending on how the future/promise is resolved.
Sebastian
On Fri, Nov 19, 2010 at 4:38 PM, Tom Van Cutsem <[email protected]> wrote:
> Hi Sebastian,
>
> Could you clarify why trapping instanceof is required for promises? It
> seems your use case can be addressed already using the current Proxy API: if
> `FP` is a function proxy, then `obj instanceof FP` will query `FP` for its
> `prototype` property (as per the default algorithm) by calling the function
> proxy's `get` trap. Inside that `get` trap, you could check whether the
> prototype is unresolved or "far" and if so, throw an exception.
>
> Cheers,
> Tom
>
> 2010/11/18 Sebastian Markbåge <[email protected]>
>
>> I thought I'd make the case for the "instanceof trap"
>> in strawman:proxy_extensions - beyond multiple inheritance. I'm sure this
>> point has been made before at some point.
>>
>> This is useful to implement various forms of promises using proxies. The
>> prototype can be resolved at a later time perhaps after some IO or lazy
>> operation. This should be able to fail if the promise is currently
>> unresolved or "far".
>>
>> It's the final piece missing to preserve "the invariants that keep the JS
>> lucid dream".
>>
>> I'm also curious to hear any objections to this proposal. I don't see the
>> same issues as with mutable prototypes being applicable to proxies.
>>
>> Sebastian Markbåge
>>
>> _______________________________________________
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
