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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
