Re: Invoke trap

2013-06-10 Thread Tom Van Cutsem
is that the invoke trap doesn't add something to the isolated graph use case. For the non-membrane proxy use case... I don't know what to think anymore... Yes, and I already agreed to that upstream: the only thing that invoke() adds is that it makes it easy and efficient to get the common case right

Re: Invoke trap

2013-06-10 Thread Tom Van Cutsem
2013/6/9 David Bruant bruan...@gmail.com Le 09/06/2013 11:37, Tom Van Cutsem a écrit : The question is whether there's a strong need for intercepting these operations. It implies a pretty strong growth of the handler API. And it's not sufficiently general-purpose to also work for exotics

Re: Invoke trap

2013-06-10 Thread Jason Orendorff
On Sun, Jun 9, 2013 at 1:28 PM, David Bruant bruan...@gmail.com wrote: For the non-membrane proxy use case... I don't know what to think anymore... I'm not sure what we're trying to do is meaningful in the non-membrane case. The properties we would like to have are: * Security - A proxy can

Re: Invoke trap (was: May 21, 22, 23 TC39 Meeting Notes)

2013-06-09 Thread Tom Van Cutsem
Hi David, 2013/6/7 David Bruant bruan...@gmail.com Le 02/06/2013 09:46, Rick Waldron a écrit : 4.4 Proxies Proxy Invoke Trap and wrong |this|-binding on built-in methods AWB: with current default behavior of “get”, “Caretaker” will break on built-ins such as Date, because

Re: Invoke trap

2013-06-09 Thread David Bruant
Le 09/06/2013 11:37, Tom Van Cutsem a écrit : I think your analysis is mostly right: if we want to make e.g. Date.prototype.getTime.call(proxy) work, then the easiest way to fit that into the current design would be to add Date-specific traps (and Map-specific, Set-specific, Regexp-specific,

Re: Invoke trap

2013-06-09 Thread David Bruant
with Map.prototype.set.call(mapProxy) (same as before without the initial mapProxy.[[handler]].get) My point is that the invoke trap doesn't add something to the isolated graph use case. For the non-membrane proxy use case... I don't know what to think anymore... David

Invoke trap (was: May 21, 22, 23 TC39 Meeting Notes)

2013-06-07 Thread David Bruant
Le 02/06/2013 09:46, Rick Waldron a écrit : 4.4 Proxies Proxy Invoke Trap and wrong |this|-binding on built-in methods AWB: with current default behavior of “get”, “Caretaker” will break on built-ins such as Date, because the |this| binding is by default set to the proxy, so the Date built

Re: Invoke trap

2013-06-07 Thread Brandon Benvie
On 6/7/2013 12:53 PM, David Bruant wrote: Le 02/06/2013 09:46, Rick Waldron a écrit : 4.4 Proxies Proxy Invoke Trap and wrong |this|-binding on built-in methods AWB: with current default behavior of “get”, “Caretaker” will break on built-ins such as Date, because the |this| binding

Re: Invoke trap

2013-06-07 Thread David Bruant
Le 07/06/2013 13:15, Brandon Benvie a écrit : On 6/7/2013 12:53 PM, David Bruant wrote: Le 02/06/2013 09:46, Rick Waldron a écrit : 4.4 Proxies Proxy Invoke Trap and wrong |this|-binding on built-in methods AWB: with current default behavior of get, Caretaker will break on built-ins

Re: Invoke trap

2013-06-07 Thread Brandon Benvie
On 6/7/2013 1:22 PM, David Bruant wrote: I don't see how this solves the issue related to Date.prototype.getTime.call( new Proxy(new Date(), handler) ) Assuming invoke also works for call and apply, if `handler` is a ForwardingHandler then that should work with getTime ultimately being

Re: Invoke trap

2013-06-07 Thread Brandon Benvie
On 6/7/2013 1:24 PM, Brandon Benvie wrote: On 6/7/2013 1:22 PM, David Bruant wrote: I don't see how this solves the issue related to Date.prototype.getTime.call( new Proxy(new Date(), handler) ) Assuming invoke also works for call and apply, if `handler` is a ForwardingHandler then that