allen at wirfs-brock.com
Mon Jan 14 08:24:45 PST 2013
On Jan 14, 2013, at 8:04 AM, Sam Tobin-Hochstadt wrote:
> On Mon, Jan 14, 2013 at 10:57 AM, Kevin Smith <khs4473 at gmail.com> wrote:
>> When a property is added to an object using a private symbol, it creates a
>> new kind of slot: a private slot. It is clear from the design of the Proxy
>> API that this represents a fundamentally new extension to the ES object
> I (as one of the people who has advocated for symbols) disagree
> entirely. The JS object model extension required for symbols is small
> -- JS objects now map from either strings or symbols to values (plus
> prototype inheritance, getters, setters, configurability,
> writeability, and the other aspects of the JS object model the quote
> below glosses over).
> The reason that the Proxy API is complex from the perspective of
> private symbols is that combining reflection with encapsulation and
> object-capability based security principles is a tricky and
> less-well-explored domain. Fortunately, Tom as well as others have
> done an excellent job with this design, and I'm confident in it.
> However, that complexity is *not* the same as complexity in the
> fundamental object model.
As further evidence, the word "private" does not even occur in sections 8.1.6 and 126.96.36.199 of the current ES6 draft. These are the sections that define the ES6 object model. Small changes and additions had to be made to allow for property keys to be either strings or symbols but those changes are independent of whether a symbol is private or not. The only place that the privateness of a symbol comes into play (besides in proxies) is in the context of a few reflection operations whose behavior is predicated upon whether a symbol property key is a private symbol or not. This is very similar to the tests that the same or similar operations make on individual property attributes.
More information about the es-discuss