Private symbols vs property attributes

David Bruant bruant.d at gmail.com
Thu Feb 7 04:23:40 PST 2013


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.

I don't have an opinion yet on whether it's a good or bad thing, but I 
just wanted to point it out.

> We should not piggyback them
> with something that is not actually related to their own semantics as
> such, but only their forwarding in specific client contexts.
>
> Let's put the distinction where it belongs. There is no systematic
> difference between privateness and non-enumerability, so they should
> be handled analogously. I hence propose that we add a new attribute to
> property descriptors, say, 'private'. Any property with this attribute
> set to true is filtered by the relevant reflective operations. That
> is, it is simply a stronger form of the non-enumerable attribute. (For
> consistency a logically inverted attribute like 'reflectable' might be
> preferable, but that's secondary.)
>
> The only drawback I see with this approach is that we have to pick a
> default.
> In particular, an assignment o[s] = v where s is a symbol
> that does not exist yet on o can only have one meaning, either
> consistently introducing a private property or a non-private one.
> There are valid arguments for either choice, but I think making the
> choice is doable.
Current string semantics begs for private:false (since 
string-as-property-name are always reflected)
But unique symbols, used as collision-free extension of built-ins could 
take the hit. I guess overriding @@iterate and @@create is also rare 
enough that using Object.defineProperty for that is also acceptable, 
leaving the PrivateSymbol semantics being the default. But I'm arguing 
for private:true by default here...
Valid arguments for either choice indeed :-)

David


More information about the es-discuss mailing list