Type of property names, as seen by proxy traps

David Herman dherman at mozilla.com
Fri Jul 8 08:41:37 PDT 2011


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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list