[Harmony proxies] Another idea to give handler access to proxies

Tom Van Cutsem tomvc.be at gmail.com
Tue Mar 1 23:38:55 PST 2011

> Of the proposals listed on the strawman wiki page, I prefer the "Proxy as
> additional argument" option. I think consistency between the traps and the
> Javascript code that they intercept is what matters most in practice, and
> what will minimize bugs for developers that are not familiar with spec.
> details. IOW, calls like "Object.defineProperty(proxy, name, pd)" would then
> be trapped by "function defineProperty(proxy, name, pd) {...}". Principle of
> least surprise and all that :-)
> Actually, under this option, you list "less consistent" as a con.
> "Consistency" is used in two different points of view:
> - The consistency listed as a con in the proxy handler API consistency
> - The consistency you're talking in your paragraph is between the proxy
> handler API and surface syntax.
> I tend to agree that

Indeed. I'll try to clarify this.

> About the last option "Proxy as argument only for particular traps", I
> think that this option should be considered only if the method list contains
> at least all methods which use prototypal inheritance. This would grow the
> list to:
> * getPropertyDescriptor
> * getPropertyNames
> * has
> * get
> * set
> * enumerate
> First, it makes sense, because in order to re-implement inheritance, there
> is a need to access prototype, which can only be done through
> Object.getPrototypeOf(proxy).
> More practically, as an example, the default 'has' trap cannot pass 'proxy'
> as an argument to the 'getPropertyDescriptor' trap if it hasn't itself a
> reference to the proxy. (actually, there is a similar issue with get set and
> enumerate)
It should be noted that this option doesn't solve the first motivating use
> case (shared handler) since some method are disadvantaged regarding, for
> instance, being able to store per-proxy state.

Sounds very reasonable. I also think that the most common reason the handler
would require access to |proxy| is to properly implement inheritance. In
that regard, we could even consider passing the prototype argument
immediately to these traps, instead of the proxy (which would decrease the
chance of runaway recursion by touching the proxy from within the handler).

As you note, that does prevent the storing-proxy-state-in-weakmaps use case,
but I don't have a good feeling of how important this use case is at the


> Cheers,
> David
>  Cheers,
> Tom
>> Cheers,
>> David
>>  Cheers,
>> Tom
>> 2011/2/28 David Bruant <bruant at enseirb-matmeca.fr>
>>>  Hi,
>>> After reading this page (
>>> http://wiki.ecmascript.org/doku.php?id=strawman:handler_access_to_proxy),
>>> I thought of another idea.
>>> Maybe that instead of adding an argument to all handler methods, we could
>>> add a property to the handler.
>>> Each time a proxy p method m is trapped (with handler h):
>>> - Object.defineProperty(h, 'currentProxy',  {value: p,
>>> configurable:true})
>>> - call the m trap (which can freely use this.currentProxy)
>>> - delete h.currentProxy (that's why the property has to be configurable)
>>> An implementation could run some static analysis to see if the handler
>>> is an actual object and if this.currentProxy is actually used in the
>>> trap to avoid the overhead of define+delete. They would have to be performed
>>> if the handler is itself a proxy.
>>> In order to reserve the 'currentProxy' (no strong conviction on the name.
>>> It could also be 'proxy') name, Proxy.create and Proxy.createFunction could
>>> throw an error is such a property is already defined.
>>> On issue is that within a handler method, I could do:
>>> {keys: function(){
>>>     Object.defineProperty(this, 'currentProxy', {value: 'gotcha',
>>> configurable:false});
>>>     }
>>> }
>>> This is notoriously stupid, but it would make the "inner delete" throw an
>>> error. The issue I'm raising is that 'configurable' controls both the fact
>>> that a property can be redefined through Object.defineProperty and deleted.
>>> Anyway, this solution sweeps away any argument positionning issue. It is
>>> very generic and for sure, any trap current or future will need access to
>>> the proxy, so it solves the problem for potential future traps.
>>> On the other hand, there may be some property configuration issues and
>>> maybe some performance issue since the two additional calls may be needed at
>>> each trap call (even though static analysis could help out with this).
>>> This idea is unperfect like the others, but it might be worth
>>> investigating in that direction.
>>> David
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110302/4acd3d38/attachment.html>

More information about the es-discuss mailing list