July 26, 2012 TC39 Meeting Notes
bruant.d at gmail.com
Wed Aug 1 20:17:06 PDT 2012
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 . 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)
More information about the es-discuss