Type of property names, as seen by proxy traps

David Herman dherman at mozilla.com
Fri Jul 8 08:40:49 PDT 2011


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



More information about the es-discuss mailing list