Private symbols vs property attributes

[Andreas Rossberg]

On 7 February 2013 13:23, David Bruant <bruant.d at gmail.com> 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