[Proxies] Refactoring prototype climbing in the spec

David Bruant bruant.d at gmail.com
Thu Nov 10 03:28:47 PST 2011


Le 09/11/2011 12:17, Tom Van Cutsem a écrit :
> 2011/11/8 Allen Wirfs-Brock <allen at wirfs-brock.com 
> <mailto:allen at wirfs-brock.com>>
>
>     More generally, I think there should be a 1::1 correspondence
>     between the internal methods in listed in ES5 Table 8 and
>     fundamental proxy traps.
>
>
> I absolutely agree we should strive to achieve this.
I disagree.

First of all, Table 8 is incomplete:
* It lacks a function for property enumeration and proxies need a trap 
for that (for-in loops, Object.getOwnPropertyNames, Object.keys).
* There is no method for passing [[Extensible]] from true to false, 
though this behavior is used and needs a ("fundamental") trap as well. 
The reason for this is certainly that this action can be described in 
one spec algorithm step, so there was no need from a specification 
perspective to consider this as an internal method, but it's still a 
fundamental operation you can perform on an object.
(I may be missing others)

A second point I disagree on is the idea of "fundamental trap". This 
notion existed on the original proxy proposal. I think it was more for 
the purpose of writing traps more easily. With the direct proxies 
proposal, the notion of fundamental and derived traps disappears (and 
hopefully, direct proxies will be promoted during the next TC-39 meeting).

Regardless of Table 8 being incomplete, I think that proxy traps have 
another factor to take into account which is the relationship with 
surface syntax. When someone writes "let a = o.a;", the intention is to 
call the "get" operation regardless of whether the "a" property is on o 
or somewhere on its prototype chain. This is another thing that I like 
in the [[Get]] refactoring: when the prototype is the proxy, its get 
trap gets called and not its getOwnPropertyDescriptor trap. It makes 
proxy traps more in line with the object clients requests.
> We might even consider eliminating [[Delete]] by defining 
> [[DefneOwnProperty]](name,undefined) to mean delete. 
Alongside with the idea of a 1::1 mapping with trap, this would make 
disappear the "delete" trap and I think it's a bad idea. Currently, I'm 
pretty happy with the idea that my delete trap is called when "delete 
myProxy.prop;" is executed.

I agree with the idea that traps should match as much as possible the 
internal object API, but i think it should be a right balance between 
the internal and external API.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111110/6579e5c2/attachment.html>


More information about the es-discuss mailing list