On 7 February 2013 13:23, David Bruant <[email protected]> wrote: > Le 07/02/2013 12:58, Andreas Rossberg a écrit : > >> We intend to have both "unique" and "private" symbols. The only >> difference between the two is that the latter are filtered from >> certain reflective operations. >> >> I have come to think that this distinction is backwards. It is >> attributing something to symbols that actually is an attribute of >> properties. Symbols are just symbols. > > This would force proxies to have the third whitelist argument regardless of > what's decided on the proxy_symbol_decoupled strawman > http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled > This is because some symbols (@@iterate, @@create, libraries extending > built-ins with symbols-as-collsion-free-property-names etc.) need to pass > proxies transparently, while what is currently private symbols shouldn't > pass by default.
The interplay with proxies is less clear, I admit. My gut feeling is that this decomposition actually frames it in the right way, and forces us to stay more honest, but I may be wrong. :) The basic idea would be that the the privacy attribute found on the target (if any), determines which operations/names are to be treated privately. For new properties, the provided attribute decides. This semantics could be amended by a white list. AFAICS, that mainly leaves the corner case of attempting to delete a property that does not actually exist on the target (because there is no privacy attribute available in that case). Should that trap? A somewhat simpler corner case is reconfiguring the privacy attribute from true to false or vice versa. I don't have a good answer for those cases off-hand, but expect them to be solvable. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
