In defense of Kevin, I too would argue that private symbols add
complexity to the object model.
That doesn't mean I'm arguing in favor of removing private symbols,
just noting that we do pay a complexity price.
We should not deny that with the addition of private symbols, we had
to reconsider every existing ES5 operation to see whether it needed to
be adjusted so that it does not leak private symbols. We happen to be
lucky that Object.keys and Object.freeze can be thought of as using
Object.getOwnPropertyNames, so adjusting gOPN (and the Proxy API)
closed all leaks identified thus far. Going forward from here, we need
to continue to be vigilant about private symbol leaks.
I also think Kevin is making the fair point that for the 99% use case,
unique symbols are sufficient. For software engineering purposes, they
provide good enough encapsulation. "private" in Java is not really
private due to java.lang.reflect, but that doesn't stop people using
it to express encapsulation.
Since Kevin is merely asking for a good explanation of why private
symbols are "in", I would say that it's because TC39 explicitly wanted
symbols to be usable for high-integrity encapsulation scenarios.
Kevin's reply to that is "if the use case is high-integrity
encapsulation, why aren't WeakMaps sufficient?"
The response to that is: WeakMaps add more boilerplate and more
overhead. I don't think the WeakMap boilerplate overhead is an actual
issue for people writing defensive code (such code already has to go
so out-of-its-way, e.g. by using early-bound primordials, I think it
can deal with WeakMaps). The performance argument still stands though.
Cheers,
Tom
2013/1/15 David Bruant <bruan...@gmail.com <mailto:bruan...@gmail.com>>
Le 15/01/2013 17:16, Kevin Smith a écrit :
The variable was called "s" standing for secret. The example
I gave was dummy, but examples in the wild are legion. Take
your favorite node library. Anytime it defines a _property,
this is where there should be a private name.
Again, that's arguable. Certainly it would be better expressed
with a symbol. But private? Are most node authors attempting to
write "secure" code? Of course not!
People writing Java code do use the private keyword. I think if
encapsulation wasn't that hard to achieve, people would do it. I'm
looking forward to see people use classes and modules without
putting more effort that they do currently and yet write more
secure code by default.
Node (by itself) does not provide a secure environment for
untrusted code.
What I know of Node makes me think it's not that much worse than
any other platform and from experience, at least much better than
anything I've played wit in PHP.
One of the goal was that no one had access to the "s" part of
the state. You need private symbols for that.
But why? Where is this strict runtime privacy requirement coming
from? What I'm not understanding is the larger context in which
mutually untrusting code supposedly shares raw (non-proxied) objects.
The reason you can't write code in any blog comment these days is
that people have given up on securing untrusted code. Likewise for
emails. HTML is used for emails, but scripts aren't executed,
because email client (web-based or not) have given up on the idea
of securing email code.
Where is the real world code doing this?
I think iGoogle does this. Otherwise, close to nowhere because
people have given up.
My guess is that they have given up because the language does not
make easy to sandbox untrusted code. As soon as you have naturally
written your code in JavaScript, it's unsafe and it takes a lot of
work making it safe. People give up. Private symbols are one tool
to lower the barrier to writing code secure by default.
For what applications? Really, I want to know! : )
They do not exist unfortunately. That's a chicken and egg problem.
As soon as it'll be easier, people will probably restart thinking
of what they want to do with the new tool they have in hand.
That's what happened when JS engines got faster. Developers didn't
stay still happy that their websites just got faster. Websites
just started to get more and more JS.
In "Crockfordian" design, "name encapsulation" and "security
encapsulation" are indistinguishable. But unique symbols address
"name encapsulation". Is there really a need to address
"security encapsulation" at the *object property level*?
It seems that it lowers the barrier to writing secure code by
default. If that's the only thing to gain, I'll take it.
Thinking more about the loading third-party code, I guess
it's technically doable to do without private names. It comes
to the cost of creating proxies doing the encapsulation for
you. You provide a blacklist of properties that must not be
reflected and the third party never sees them... In essence,
you're listing the private properties and the proxy does the
book keeping (details about non-configurability aside).
Sure - and approaches like this (or simpler - people are clever!)
can be factored away into a neat library, without having to mess
with the underlying object model.
ES6 provides WeakMaps and Proxies. Why not see what people do
with those before introducing private slots?
I wouldn't be opposed to that, but that's just my opinion. Still,
private symbols allow property-like syntax. I haven't followed the
latest developments of how classes and private symbols interact,
but I'm not too worried it goes well. Assuming it does, it makes
it easy for people to use actually private properties in their
code, lowering the barrier to writing well-encapsulated code.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
