May the defineProperty method of a proxy handler throw a TypeError?

Tom Van Cutsem at
Fri May 27 01:53:35 PDT 2011

2011/5/26 David Bruant <david.bruant at>

> Le 26/05/2011 18:44, David Flanagan a écrit :
> > On 5/26/11 6:51 AM, Sean Eagan wrote:
> >> Is think it would beneficial to replace all this.* calls in the
> >> default trap implementations with Object.* methods and syntax that
> >> subsequently triggers the this.* calls.  This would guarantee that
> >> none of the internal object semantics are being missed, and
> >> implementations could still optimize just as easily.
> We have been discussing whether this.trap was equivalent to Object.trap
> (shorthand notation) and the conclusion was that there was no way to
> distinguish both cases. I think there actually is.
> If, in a handler, I do "this.defineProperty(23, {value:1})", there is no
> conversion of the first argument to a string while there is if I
> internally call "Object.defineProperty(proxy, 23, {value:1})"
> There are probably other such cases.
> And I agree with Sean. this.trap calls should be replaced with Object.*
> calls

The current API doesn't allow this as changing |this.*| to |Object.*|
requires the handler to have access to the |proxy| in all traps. But if <> is
accepted, this seems like a good suggestion.

> > With specification text "as if by calling the primordial Object.*
> > function"?  So that user modifications to Object.* are not observable?
> I would argue so.
> (by the way, ES5 terminology says "built-in" where you say "primordial")
> > Wouldn't that mean that a pure-JavaScript implementation of the
> > default traps would not be possible from a module that could not run
> > at interpreter startup?  (That may not be a goal that anyone has, of
> > course.)
> Is it a goal at all?
> There are plenty of things that are not possible anymore after one
> starts messing around with built-in. I wouldn't be shocked by adding
> this one.
> I will always be in favor that derived traps should be implementable
> with pure JS in a fresh environment, but when the environment isn't
> fresh, it don't think it's worth worrying about such a guarantee.

I agree. I think it would be good to specify the built-in implementation of
derived traps to always invoke the built-in Object.* methods. This allows
engines to fully optimize. It is still possible for JS programmers to
faithfully implement the default behavior in JS, given a consistent
environment (consistent meaning here that Object.* methods may even have
been monkey-patched, but remain faithful to their ES5 semantics).

> > Personally, I think that proxies would be easier to reason about if no
> > distinction was made between fundamental and derived traps.
> Based on my experience with proxies, there are very few cases which
> really require to re-implement all traps. Reimplementing the
> fundamentals and letting the engine handle inheritance + hasOwn trap is
> handy.
> > I'd put that distinction in an abstract Proxy.Handler class and then
> > rename the current Proxy.Handler to Proxy.ForwardingHandler.
> What do you call a "class" is is a constructor with some arguments?
> Could you provide a code snippet of how you'd see it work.
> Also, I think that this strawman
> (
> )
> is a first step toward what you're asking.
> I've also raised the idea of renaming what is currently called
> Proxy.Handler. It's still in discussion I think. I remember that Tom had
> an idea, but I don't remember which.

My latest suggestion was to rename Proxy.Handler to Proxy.Forwarder
(Proxy.ForwardingHandler is a mouthful).

The idea of the cited strawman would be that Proxy.Forwarder inherits from
Proxy.BaseForwarder. BaseForwarder implements a forwarding implementation of
all the fundamental traps. Forwarder then adds a forwarding implementation
for the derived traps. Programmers can then create handlers that inherit
from either one of these prototypal handlers, and override only a select
number of traps, relying on the inherited implementation for the other
traps. This seems to be in line with what David F. is proposing.


> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list