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. 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. A property of the other form would have to be introduced via Object.defineProperty, until we get more syntax support. (Note that this only affects installing a new property, not later assignments.) /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
