Proxy forwarding handlers and accessor properties

David Bruant david.bruant at
Fri Jun 17 04:28:25 PDT 2011

Le 17/06/2011 08:42, David Flanagan a écrit :
> On 6/16/11 5:20 PM, David Bruant wrote:
>> Le 17/06/2011 01:54, David Flanagan a écrit :
>>> // When we create a proxy with a forwarding handler, though, the this
>>> value
>>> // is different in the two cases.
>>> var handler = {
>>>      target: o,
>>>      get: function(receiver, name) {
>>>          return[name];  // Same as 
>>> Proxy.Handler.prototype.get
>>>      }
>>> }
>> If you get rid of the "get" trap (you need a getOwnPropertyDescriptor
>> trap though), the default get (derived) trap will be called instead and
>> basically do what you do afterward (call to getOwnPropertyDescriptor
>> trap which will call Object.getOwnPropertyDescriptor(,
>> name) The 'this' binding is performed by the
>> engine (with the receiver as value) after the property descriptor has
>> been returned (as explained in strawman:proxy_drop_receiver).
> Thanks.  I didn't realize that the default get behavior was to do what 
> I put in my second handler.
Besides type checking, the code is the same than yours for the get trap.
In a way, it's reassuring that people experimenting like you do reach 
the same solution to the same problem independently.

> Still, my basic question remains, though: is it a bug that a 
> forwarding proxy created with Proxy.Handler behaves differently in 
> this way (this value in methods is different than the this value for 
> accessors) than the object to which it forwards?
I do not think it's a bug. What happens with your code is coherent with 
ECMAScript (and apparently, the JS implementation is consistent with 
that too).
I think that a more important question is: "can you achieve what you 
want (giving the impression that "this" is the same for both 
getters/setters and methods) with the current proxy API?". If so, is it 
"natural" or is it a hack?
Apparently, you can achieve what you want and my opinion is that the 
solution is natural (using the derived trap default behavior). Removing 
a trap to achieve your goal may sound not natural, but 
strawman:derived_traps_forwarding_handler seems to be a decent solution 
for that.

> (Originally I had a second question about the proposed removal of the 
> receiver argument, but now I understand that that strawman is 
> contingent on the addition of a proxy argument to the handler methods, 
> so let's disregard that second question...)
Yes, I'm sorry, I should have mentionned that. I tend to consider this 
strawman as already accepted since it sounds so natural to me and has 
found several justifications on es-discuss. It is however true it still 
needs to be accepted (July TC-39 meeting, hopefully?) and SpiderMonkey 
will need to be adjusted consequently.


More information about the es-discuss mailing list