On Feb 7, 2013, at 3:58 AM, Andreas Rossberg wrote: > 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.) >
Note that the enumerable attribute really only affects for-in enumeration (and Object.keys), neither of which enumerates symbols anyway. That, means that the enumerable attribute really has has no current meaning for symbol keyed properties. That means we could probably reinterpret the enumerable attribute as a "private" attribute for such symbol keyed properties. For now, I'll reserve comment on whether or not any of this is a good idea and related issues such as proxy impacts. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
