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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
