And just to be clear, I meant produce in the sense of producer/consumer relationship on the trap functions, not in the generative sense.
Dave On Jul 8, 2011, at 8:40 AM, David Herman wrote: > 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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
