Sorry, yes. Too early in the morning for me. :) Indeed, handler traps are exactly the place where the system *produces* names and hands them to handler traps which consume them, and that's where it must produce a public key rather than a private name object.
Dave On Jul 8, 2011, at 8:20 AM, Brendan Eich wrote: > On Jul 8, 2011, at 7:17 AM, David Herman wrote: > >>> The proposal does mention: "All reflective operations that produce a >>> property name, when reflecting on a private name, produce the name’s >>> .public property instead of the name itself." >>> >>> Would the same hold for reflective operations that consume property names, >>> such as handler traps? >> >> No, they would require the private name object. > > I don't think that's what Tom was asking about, though. The proposal may > simply be unclear in using "produce" instead of "consume" since the proxy > mechanism does not produce private names in any generative sense when one > writes p[q] for proxy p and private name q. > > Rather, the VM substitutes q.public for q when calling p's handler's relevant > trap (getOwnPropertyDescriptor, get, ...). So there's no leak, as you note, > and the owner of q is free to share it with trap implementations that should > have access to it, so they can compare name == q.public, memoize in q.public > in a weak map, etc. > > /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
