Proxy target as __proto__? (Re: Proxy's optional target)

# Claus Reinke (13 years ago)

The proxy target is important because it specifies some invariants about the proxy (typeof, builtin brand, behavior of forwarding for unspecified traps, values of internal properties like [[DateValue]], [[NumberValue]], etc.).

That is probably the most important difference between direct proxies and old-style proxies. Yet I find it slightly limiting and accident-prone: it uses invariants and target to make proxies not just behave like an object, but to behave like the target.

Presentations on direct proxies tend to present too usage patterns: wrapped objects and virtual objects.

My problem is: if I am using proxies as wrappers, I want to use the target object as a -wait for it- prototype, to be modified by the proxy. But if the target object happens to be frozen, modified returns are no longer allowed by the invariants. To cover this eventuality, I should use the virtual object pattern even if I just want to wrap an object!

Would it be possible/helpful to use the target merely as a proto instead of a harness, inheriting the target's internal properties without over-constraining the proxy's ability to modify the wrapped target's behavior? Invariants could still use an implied object for freezing the proxy, so the proxy would behave as an object, not necessarily the same as the target object.

Claus

# Tom Van Cutsem (13 years ago)

I'm not sure I fully understand your proposal, but could you not achieve it by simply doing:

var target = ...; // might be frozen var p = Proxy( Object.create(target), handler);

?

Cheers, Tom

2013/1/17 Claus Reinke <claus.reinke at talk21.com>

# Claus Reinke (13 years ago)

I'm not sure I fully understand your proposal, but could you not achieve it by simply doing:

var target = ...; // might be frozen var p = Proxy( Object.create(target), handler);

Ah, too obvious for me, thanks!

Also, proxy wrappers often modify functions, which tend to be on a non-frozen prototype. So perhaps it isn't as big an issue as I thought.

Claus

PS. I probably shouldn't mention that Proxies' invariant checks only against own properties behave differently from how non Proxy objects behave, if a target prototype property happens to be frozen (override prohibition non-mistake)?

var x = Object.freeze({foo: 88}); var y = Object.create(x);

y.foo = 99; // fail console.log( y.foo ); // 88

var yp = Proxy(y,{get:function(t,n,r){ return n==="foo" ? 99 : t[n] } }); console.log( yp.foo ); // 99

# Tom Van Cutsem (13 years ago)

2013/1/18 Claus Reinke <claus.reinke at talk21.com>

PS. I probably shouldn't mention that Proxies' invariant checks only against own properties behave differently from how non Proxy objects behave, if a target prototype property happens to be frozen (override prohibition non-mistake)?

var x = Object.freeze({foo: 88}); var y = Object.create(x);

y.foo = 99; // fail console.log( y.foo ); // 88

var yp = Proxy(y,{get:function(t,n,r){ return n==="foo" ? 99 : t[n] } }); console.log( yp.foo ); // 99

Yep, this is true. But it doesn't violate any invariants since we could have made y.foo return 99 as well, if we had used Object.defineProperty to shadow 'foo'.