Private Slots

Andreas Rossberg rossberg at
Thu Jan 17 05:22:04 PST 2013

On 15 January 2013 17:16, Kevin Smith <khs4473 at> wrote:
>> It's really none of your business when you try to freeze my object whether
>> any of
>> (a) pre-existing private-symbol-named properties remain writable;
>> (b) weakmap-encoded private state remains writable;
>> (c) objects-as-closures environment variables remain writable.
>> Really. Not. Your. Business!
> But that's a change from the current object model and by (a) you're assuming
> the conclusion.  ES has a really simple object model, as explained in the
> first part of the ES5 specification.  That simplicity is an advantage.  If
> you're going add complexity, then it should be justified with
> application-focused use cases.  That request does not seem like a stretch to
> me.

Just to throw in one more opinion, I sympathise with Kevin to some
extent. Despite Sam's argument, I think there is considerable
complexity imposed by private names, and it has been increasingly
unclear to me that it is really warranted at this point. It might be
worth reconsidering and/or post-poning, and Kevin made a few good
arguments to that end later down the thread.

(However, I don't follow your description of the ES5 object model
being "really simple". With sufficient squinting, you may call the ES3
model (relatively) simple, but ES5 certainly put an end to that. Now,
ES6 is adding several whole new dimensions of complexity, all of which
dwarf private symbols. Let alone a potential Object.observe in ES7. In
fact, there are very few languages that have an object model more
complicated than that. ;) )


More information about the es-discuss mailing list