July 26, 2012 TC39 Meeting Notes

[David Bruant]

Le 18/09/2012 10:44, Tab Atkins Jr. a écrit :
> On Tue, Sep 18, 2012 at 10:12 AM, Tom Van Cutsem <tomvc.be at gmail.com> 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