[Proxies] Refactoring prototype climbing in the spec
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss