Private Slots

David Bruant bruant.d at
Wed Jan 16 14:59:11 PST 2013

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


More information about the es-discuss mailing list