Discuss
  • [Harmony proxies] "if a trap is missing"

[Harmony proxies] "if a trap is missing"

# David Bruant (14 years ago)

"All traps are optional. If missing (more precisely, if handler[trapName] returns undefined), the proxy defaults to forwarding the intercepted operation to its target object." [1]

Proxy({}, {get:undefined}).someProperty;

In this case, the description says that the operation is forwarded. I would prefer a TypeError to be thrown in this case.

Opinions?

David

[1] harmony:direct_proxies

# Xavier MONTILLET (14 years ago)

Imagine you have a proxy set dynamically, meaning that you don't have the traps written in the code, you just pass variables. Then you need the undefined value to behave the way it does or you can't default to forwarding.

But I think there is a need to "disable" a trap. Meaning that instead of forwarding, it would throw an error. So I'd say:

var p =Proxy({prop:1}, {get:undefined,set:null}); p.prop;// 1 p.prop = 2;// error: no set trap

# David Bruant (14 years ago)

Le 07/12/2011 19:23, Xavier MONTILLET a écrit :

Imagine you have a proxy set dynamically, meaning that you don't have the traps written in the code, you just pass variables. Then you need the undefined value to behave the way it does

You don't need undefined, you can delete the property.

or you can't default to forwarding.

Even if you couldn't delete the property, you can implement the default behavior in JavaScript. Something along the lines of: function trap(...args){ return Reflect.trap(...args); } The default handlers will be also provided in a module if I recall correctly.

But I think there is a need to "disable" a trap. Meaning that instead of forwarding, it would throw an error. So I'd say:

var p =Proxy({prop:1}, {get:undefined,set:null}); p.prop;// 1 p.prop = 2;// error: no set trap

I've proposed once that in some API, null and undefined had different semantics and someone (Brendan, maybe?) said that there is no precedent of this. I would assume the same stands here (and is another argument to trigger default trap on property non-existence rather than undefined)

If someone ever considers changing traps dynamically, the trouble will be hard enough by itself and I think the language should do as much as possible to help catching errors early.

function h(g, s){ return {get: g, set:s}; }

var p = Proxy({}, h(function(...args){console.log(args);})); p.a = 1;

I would claim that in this (simplified-maybe-not-fully-realistic) case the missing second argument in the h function is very likely to be a bug and I would be thankful to the language to warn me about it.

# Tom Van Cutsem (14 years ago)

2011/12/6 David Bruant <bruant.d at gmail.com>

"All traps are optional. If missing (more precisely, if handler[trapName] returns undefined), the proxy defaults to forwarding the intercepted operation to its target object." [1]

Proxy({}, {get:undefined}).someProperty;

In this case, the description says that the operation is forwarded. I would prefer a TypeError to be thrown in this case.

To do this, the proxy would need to test whether the trap actually exists, by performing an "in" test on the handler. This breaks the double lifting pattern [1], which depends on the only interaction between the proxy and the handler being property access.

Aside from that main issue, I think it would be odd for Proxy({},{}).foo to just work while Proxy({},{get:undefined}).foo would fail with a TypeError.

Cheers, Tom

[1] See harmony:reflect_api, last

code snippet under "Forwarding".

# David Bruant (14 years ago)

Le 07/12/2011 21:21, Tom Van Cutsem a écrit :

2011/12/6 David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>>

"All traps are optional. If missing (more precisely, if
handler[trapName] returns undefined), the proxy defaults to forwarding
the intercepted operation to its target object." [1]

Proxy({}, {get:undefined}).someProperty;

In this case, the description says that the operation is forwarded. I
would prefer a TypeError to be thrown in this case.

To do this, the proxy would need to test whether the trap actually exists, by performing an "in" test on the handler. This breaks the double lifting pattern [1], which depends on the only interaction between the proxy and the handler being property access.

True.

Aside from that main issue, I think it would be odd for Proxy({},{}).foo to just work while Proxy({},{get:undefined}).foo would fail with a TypeError.

On one hand I like when the language throw errors (I'm aware I'm not a majority with this point of view) On the other hand, while writing handlers, it can be a very good practice to explicitely state {trap:undefined} to be sure that the intention of the programmer was to have the default behavior.

So yeah, undefined-as-a-value and property non-existence having the same behavior is a good idea indeed.