Le 01/08/2012 14:25, David Bruant a écrit :
The "big saving" is that the public->private mapping and return value
boilerplate code to be put in all name-accepting traps is entirely
replaced by a one-liner in the handler definition. Something like
"isPrivateNameKnown: Set.prototype.has.bind(privateNamesIKnow)"
(privateNamesIKnow is either shared in handler function scopes or as a
handler property or something else, left at the discretion of the author).
It's likely to be a slightly bit more efficient in both time (no need
for the after-trap private name checking, no need for public->private
nor for the 2-properties array) and memory (no need for public
counterparts any longer).
Also, public->private resolution and returning the right private name
seems more error prone than if you're being handed the private name
directly as an argument. Maybe debatable.
To follow-up on that part, here is a gist with the difference between
what the current proposal is and the alternative proposal [1]. The gists
focuses only on the parts that would differ from one proposal to the
other. Specifically, I've omitted the update of the WeakMap/WeakSet
which is necessary to do manually in both cases.
Besides the reduced boilerplate, the exercice of writing this made me
realize that the setName and definePropertyName traps of the current
proposal leak the value to be set to the target when the private name is
unknown. This makes the protection of getName and
getOwnPropertyDescriptorName return values somewhat ridiculous.
Also, I've changed my initial proposal a bit with regard to unknown
private names. Now, there is just one trap that's called when that
happens. No argument is passed, only the operation as a string ('get',
'set', 'hasOwn', etc.). As Tom noted, the only useful thing one can do
when the private name is unknown is throw or forward, so this trap lets
you decide based on which operation is being performed (this can
probably be useful for read-only proxies)
David
[1] https://gist.github.com/3232772
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
