July 26, 2012 TC39 Meeting Notes

David Bruant 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 [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


More information about the es-discuss mailing list