Private Slots

Allen Wirfs-Brock allen at
Wed Jan 16 14:05:06 PST 2013

On Jan 16, 2013, at 12:57 PM, Russell Leggett wrote:

> On Wed, Jan 16, 2013 at 3:48 PM, Brendan Eich <brendan at> wrote:
> Mark S. Miller wrote:
> My position on private symbols.
> My position on classes is and has always been that classes are worth
> introducing into the language*only*  if they give us, or can be used
> with, an affordable means for true object encapsulation. Assuming
> Allen is right about what actual implementors will do (which I find
> plausible) then WeakMaps are not that means. Given other discussions,
> I am confident that the objects-as-closures pattern will not become
> efficient either -- it is likely to continue to cost an allocation per
> method per instance as its semantics naively suggests. So of the
> options practically on the table, I think private symbols are the only
> workable choice. If this is correct, then I consider private symbols
> to be a requirement. Am I missing anything?
> I agree, but David Bruant is arguing for weakmap-with-hint still, and Kevin is arguing (my summary) "YAGNI" to high-integrity privacy, not exclusively but for most developers -- and for the SES minority, weakmaps are enough.
> I think Kevin's argument is pretty strong. SES is definitely not everyone, and unique is pretty powerful, especially if you make the slot non-enumerable. The when in doubt... argument has been made. ES6 is pretty stuffed as it is. Thinking about ES7, though, I thought of a possibly interesting place that might be more fitting for private style slots.
> I've thought about the tradmark( proposal a lot, because I keep hearing the notion of a brand being used as a reason for a private symbol. Perhaps branding could be implemented with private symbols... *or* perhaps high-integrity privacy could be related with brand. A brand could open the door to ADT/typeclass/protocol style abstractions, and perhaps that is a better location for privacy.

I normally a behaviorist and don't care whether the contract compliant object you pass me is one that I certifiably created or one you created.  However, in some situations being able to identify "trusted" objects is an absolute requirement and in even more situations it is a perceived requirement.  Being able to identify such trusted object, is what I call branding.  The poster child that I hold up for this isn't SES (although it apparently does requiring branding) but the DOM.  The DOM designers really believe that most DOM objects need to be branded in this manner.

An explicit goal of ES6 is to support self hosting of important native libraries including the DOM. Self hosting libraries will be practical only if the self hosted implementation can approach native performance and that includes any overhead for branding, where it is required.  In my previous message I explained why we shouldn't expect WeakMap based branding, in practice, to perform competitively with private Symbol based branding.  If we remove private Symbols from ES6 and assume that WeakSymbols aren't a perf competitive solution then the only branding solution (for use cases like the DOM) that I see remaining is something based upon using Proxies. But that would mean that essentially every DOM object would have to be represented using a Proxy but proxies themselves impose performance issues and currently (using private Symbol branding) most DOM objects don't need to be proxies. 

Private Symbols actually have very little impact upon the core ES specification and presumably implementations.  The only place they introduce any real complications is in the semantics of proxies.  And even there, the complications are manageable.  In fact, if I really wanted to conceptually simplify ES6, I would look at eliminating or simplifying Proxy before I would look to eliminate private Symbols.

Private Symbols are a good pragmatic engineering solution to a very real problem. We really should move forward with them. I don't think we can wait for ES7 .

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

More information about the es-discuss mailing list