Proxy-induced impurity of internal methods

Andreas Rossberg rossberg at google.com
Mon Oct 10 08:02:45 PDT 2011


On 10 October 2011 15:38, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> This point was previously noted, see:
> <http://wiki.ecmascript.org/doku.php?id=strawman:proxy_set_trap>
> It was brought up at the March 2011 meeting, and IIRC we were in agreement
> that the spec. should be adapted to remove the redundant
> getPropertyDescriptor call.

Ah, thanks. I wasn't aware of that. Good to hear.

>> In a number of places, the ES5 spec makes hidden assumptions about the
>> purity of internal method calls, and derives certain invariants from
>> that, which break with proxies.
>>
>> For example, in the spec of [[Put]] (8.12.5), step 5.a asserts that
>> desc.[[Set]] cannot be undefined. That is true in ES5, but no longer
>> with proxies. Unsurprisingly, both Firefox and V8 do funny things for
>> the following example:
>>
>> ----------------
>> var handler = {
>>  getPropertyDescriptor: function() {
>>    Object.defineProperty(o, "x", {get: function() { return 5 }})
>>    return {set: function() {}}
>>  }
>> }
>> var p = Proxy.create(handler)
>> var o = Object.create(p)
>> o.x = 4
>> ----------------
>>
>> Firefox 7: InternalError on line 1: too much recursion
>> V8: TypeError: Trap #<error> of proxy handler #<Object> returned
>> non-configurable descriptor for property x
>
> (are you sure this tests the right behavior? It seems the V8 TypeError is
> simply due to the fact that the descriptor returned from
> getPropertyDescriptor is configurable.)

You are right, of course. If I make it configurable, V8 returns
without error. However, by modifying the example somewhat you can see
that it executes the setter from the descriptor then. That is not
quite right either (Though neither wrong, I suppose :) ).

> I agree. In fact, proxies already abandon the CanPut/Put split: they
> implement CanPut simply by always returning true, and perform all of their
> assignment logic in [[Put]]. Related to this refactoring: Mark has
> previously proposed introducing a [[Set]] trap that simply returns a
> boolean, indicating whether or not the assignment succeeded. The [[Put]]
> trap would simply call [[Set]], converting a false result into a TypeError
> when appropriate (cf.
> <http://wiki.ecmascript.org/doku.php?id=harmony:proxy_defaulthandler#alternative_implementation_for_default_set_trap>).
> We don't have consensus on this yet. I would propose to discuss the
> CanPut/Put refactoring and the [[Set]] alternative together during the Nov.
> meeting.

Yes, that makes sense.

On 10 October 2011 16:01, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> I will go over the proposed proxies spec to check whether there is actually
> any harm in allowing a proxy to become non-trapping during an active trap.
> If the proxy describes a coherent object before and after the state change,
> there is no reason to disallow this. The new proposal Mark and I have been
> working on may help here, since it enforces more invariants on proxies.

I'm not sure I understand what you mean by "becoming non-trapping",
can you elaborate? What would it do instead?

/Andreas


More information about the es-discuss mailing list