>
>
> 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! Node (by itself) does not provide a secure
environment for untrusted code.
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.
Where is the real world code doing this? For what applications? Really, I
want to know! : )
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*?
> 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?
{ Kevin }
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
