Private symbols vs property attributes
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
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
> 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 :-)
More information about the es-discuss