Le 18/09/2012 10:44, Tab Atkins Jr. a écrit :
On Tue, Sep 18, 2012 at 10:12 AM, Tom Van Cutsem <[email protected]> wrote:
I wrote up a strawman that summarizes the discussion on proxies & private
names in this thread:
http://wiki.ecmascript.org/doku.php?id=strawman:proxies_names
There are still some open issues though.
I like it! Seems to work pretty well, and the fact that it allows us
to actually pass the private name itself around is very nice and
simple.
Changing to an unknownPrivateName() trap is interesting. It seems
kinda weird to be a *trap*, rather than just a property on the handler
object, though. Is there a good reason to have that be dynamic?
A proxy might want to throw on unknownPrivateNames for write traps, but
not read traps. As I'm writing that, I realize that I had suggested to
have the operation ('get', 'set', 'defineOwnProperty'...) as argument of
the unknownPrivateNames trap (but not the arguments of the operation
itself), but this isn't in the strawman.
That would be the only reason I see to have the unknownPrivateNames as a
trap.
Regarding resolvePrivateName+public part, the use case isn't clear. The
whitelist allows for proxies to expresse knowledge a dynamic set of
names, I don't really see how what more a "resolve" trap enables.
As said in the strawman, now that we have the whitelist, we can get rid
of the public part of private names, which is one less burden on the
shoulders of implementors.
In the worst case, if someone comes up with a use case that requires
unique names, a public part and additional argument to
unknownPrivateNames can be added in a later version of the spec.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
