Private Slots

Kevin Smith khs4473 at
Tue Jan 15 11:01:26 PST 2013

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

WeakMaps provide a new feature without extending the object model.  They
are "external" to objects, if you like.

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

Sure - but I'm not objecting to closed-over state (in any form).  That
would be ludicrous.  : )

>  and by (a) you're assuming the conclusion.
> No, I'm saying the horse already left the barn.

Again, not objecting to private state.  But just because we allow private
state, it does not necessarily follow that we should mess with the object
model to accomodate it.  Maybe it's worth it, I don't know.  That's the
whole point:  I don't know.  And when in doubt...

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

But is this not premature optimization?  How do I know that WeakMaps and
Proxies are insufficient?

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

Again, aren't we optimizing private state lookup without field testing?  I
hear people say "me wants private!" but for the common case, I'm not seeing
the need for runtime security.  Not yet anyway.  I want to understand the
security model that would motivate such a universal need.

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list