Private Slots

Brendan Eich brendan at
Tue Jan 15 10:32:14 PST 2013

Kevin Smith 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

(b) is a change from ES5 but you don't object to weak maps -- why not?

(c) is not a change from JS's object model!

> and by (a) you're assuming the conclusion.

No, I'm saying the horse already left the barn.

>  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.

Of course, we justified weak maps with specific use-cases. Those do not 
cover private symbols, because private symbols are really "in" the 
object, they do not identify storage in a side table. This matters when 
abstracting over strings or symbol (private or unique) property names, 
as I showed. It matters when using the bracketing operator (a weak map 
would have to be exposed and its use transposes operands of []). It 
matters for any future private syntax.

Finally, efficiency does matter. The GC cost of weak maps is just one 
cost I mentioned. The property access cost is another, which you did not 


More information about the es-discuss mailing list