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

David Bruant david.bruant at labri.fr
Thu May 26 10:46:24 PDT 2011


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


> 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.


> 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
(http://wiki.ecmascript.org/doku.php?id=strawman:derived_traps_forwarding_handler)
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.

David


More information about the es-discuss mailing list