Private Slots

Brandon Benvie brandon at
Wed Jan 16 15:20:52 PST 2013

It's worth noting that private Symbols *are* used by the ES6 spec to solve
a number of other problems currently. They are used to provide easy to use
hooks for overriding builtin functionality: @@hasInstance, @@create,
@@toStringTag, @@iterator, and @@ToPrimitive. Some of these (@@toStringTag,
@@iterator) likely make sense as unique symbols, but the others protect
access to powerful capabilities that should likely be protected. Without
private symbols, it would be difficult to expose these APIs in the easily
hookable manner they are provided now. Using prototypal inheritance along
with private symbols to protect access is exactly how these hooks are made
easy to use.

On Wed, Jan 16, 2013 at 5:59 PM, David Bruant <bruant.d at> wrote:

> Le 16/01/2013 21:48, Brendan Eich a écrit :
>  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
> Let's say I'm "exploring" rather than "arguing for"
>  and Kevin is arguing (my summary) "YAGNI" to high-integrity privacy, not
>> exclusively but for most developers
> The current practice of everything-public in JS, in my opinion, is derived
> from the low-energy path developers take when they write JS code. If the
> natural thing to use is a high integrity tool, they'll use it and get all
> the benefits from it without even thinking about it.
> That's what happens with "private" in Java (I don't think most Java devs
> think that the Reflect API makes their private attributes actually not
> private). Java devs could make everything public, they choose not to
> because the cost of putting "public" is the same as the cost of putting
> "private" and the benefits are known. In ES5, high integrity privacy has a
> cost both in code readability and runtime, that's why people don't use it.
> It's not that they don't need it, it's just that getting to high integrity
> is annoying.
> Most developers didn't think they needed JSON.parse so they didn't bother
> downloading json2.js and used eval (4 characters, very low-energy) to
> create objects out of XHR-retrieved strings. We know the outcome.
> Most developers (most human beings?) do not know what they need. They have
> a job to accomplish, a set of tools they're aware of and they work to find
> the easiest way ("low-energy") to get to the goals using the tools they
> have. The easy way is to attach information to an object is to use
> properties? That's what people use, end of story, no strong reflection on
> what they "should" be using or what they "need".
> The easy way to add a getter is to use __defineGetter__? That's what
> people use in Node.js. Fortunately, it has no consequence on security.
> A language like Rust fascinates me primarily because the easiest way to
> write something in Rust is to write safe code (it's actually the only way),
> while the easiest way to write C code...
> I think the "most developers" argument is upside down. Most developers
> strive for "easy" with few thoughts on the exact properties they need. They
> want to have their website working, that's all most developers care about.
> If easy is secure by default, they get security for free, just doing their
> job. If easy isn't secure by default, they're in a better or worse
> eval(jsonString) situation.
> ES6 needs to change the language to make high-integrity the thing most
> developers will naturally use by default in their low-energy path. I think
> this relates to Mark's above argument about the condition on whether
> classes are worth it.
> Every project of a decent size needs high-integrity privacy. This
> shouldn't have a barrier to entry. It should just be what people do by
> default. Security shouldn't be considered as a luxury left to experts. It
> should be what naturally comes from writing our code.
> Take a microwave. It stops when you open the door. This is because human
> beings do open the door when the time isn't up yet. Microwaves have just
> been designed to be safe when human beings naturally interact with them.
> I shouldn't have to learn how to use my microwave safely. I may need to
> learn how to take care of it in the long term (clean it up every once in a
> while...), but I'm in right to expect that the microwave is designed so
> that how I naturally interact with it is safe.
> I live on the second floor. On my balcony is a barrier. When I go on my
> balcony, gravity says the low-energy path is to fall. With the barrier, I
> have to make quite an effort to fall; my balcony has been designed so that
> the way I naturally interact with it is safe.
> In my opinion, ES6 should be a microwave or a balcony and not expect
> people to be experts and use convoluted patterns to be used safely.
> David
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list