I wrote up a draft strawman for making this change:
http://wiki.ecmascript.org/doku.php?id=strawman:proxy_drop_receiver.
2011/4/28 Tom Van Cutsem tomvc...@gmail.com
Hi,
I think Sean is correct: under the ES5 semantics, the receiver argument
to get and set is not required, because get and
Le 27/04/2011 23:09, Sean Eagan a écrit :
As explained before, the existing ES5 semantics would cause the proxy's
getPropertyDescriptor trap to be called thus obtaining any getter
/ setter that the proxy wants. The |this| binding of this getter
/ setter will then be set to the receiver by ES5
On Apr 28, 2011, at 1:26 AM, David Bruant wrote:
Le 27/04/2011 23:09, Sean Eagan a écrit :
As explained before, the existing ES5 semantics would cause the proxy's
getPropertyDescriptor trap to be called thus obtaining any getter
/ setter that the proxy wants. The |this| binding of this
Hi,
I think Sean is correct: under the ES5 semantics, the receiver argument to
get and set is not required, because get and set are not supposed to
be invoked on a proxy acting as a prototype. In both cases, property lookup
is indeed via [[GetProperty]]. That means get will only ever be invoked
Hi,
The get and set traps currently have both receiver and proxy
arguments. This is because it has been suggested that they are not
the same in the case of property access on a receiver causing a
[[Get]] / [[Put]] call to propogate up the prototype chain to a proxy.
From what I can tell though,
Le 27/04/2011 19:38, Sean Eagan a écrit :
Hi,
The get and set traps currently have both receiver and proxy
arguments. This is because it has been suggested that they are not
the same in the case of property access on a receiver causing a
[[Get]] / [[Put]] call to propogate up the prototype
Hi David,
On Wed, Apr 27, 2011 at 1:17 PM, David Bruant david.bru...@labri.fr wrote:
The case when they are not the same is when the proxy is in the
prototype chain (regardless of what kind of object is underneath).
See the third example at:
Le 27/04/2011 20:37, Sean Eagan a écrit :
Hi David,
On Wed, Apr 27, 2011 at 1:17 PM, David Bruant david.bru...@labri.fr wrote:
The case when they are not the same is when the proxy is in the
prototype chain (regardless of what kind of object is underneath).
See the third example at:
This can also be seen by realizing that if proxyA's handler uses the
default get and set trap implementations, and proxyB is proxyA's
[[Prototype]], then proxyB's get and set traps will not be called
due to property access on proxyA, but rather its
getPropertyDescriptor trap.
Thanks,
Sean Eagan
Sorry, ignore the first paragraph in my last post, I included it at
the end instead. Thanks.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Le 27/04/2011 21:15, Sean Eagan a écrit :
This can also be seen by realizing that if proxyA's handler uses the
default get and set trap implementations, and proxyB is proxyA's
[[Prototype]], then proxyB's get and set traps will not be called
due to property access on proxyA, but rather its
On Wed, Apr 27, 2011 at 2:46 PM, David Bruant david.bru...@labri.fr wrote:
You're right. get and set default traps were chosen to follow
closely internal methods (see [1]) and at the time when proxy wasn't
an argument of all traps (so a proxy's prototype wasn't reachable from
the handler).
It
On Apr 27, 2011, at 2:09 PM, Sean Eagan wrote:
As explained
before, the existing ES5 semantics would cause the proxy's
getPropertyDescriptor trap to be called thus obtaining any getter
/ setter that the proxy wants. The |this| binding of this getter
/ setter will then be set to the receiver
13 matches
Mail list logo
