July 26, 2012 TC39 Meeting Notes
bruant.d at gmail.com
Tue Sep 18 02:04:29 PDT 2012
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:
>> 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
> 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
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.
More information about the es-discuss