Le 14/01/2013 17:45, Kevin Smith a écrit :
No boilerplate, no additional runtime costs than what's necessary.
Arguably, all of those examples could be addressed by unique symbols.
Where is the need for strong runtime enforcement of encapsulation?
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.
One of the goal was that no one had access to the "s" part of the state.
You need private symbols for that.
I would personally like to see answers to the following questions:
- Do private slots enable applications that would otherwise be
impossible?
I guess applications where you need memory for your actual content
and not memory to compensate the lack of language expressiveness.
I have no real idea of how much can be saved in terms of memory
between the 3 snippets I've shared with millions of C instances.
Private symbols are not necessary for this. Unique symbols work just
fine.
The implicit requirement was that only trusted parties were expected to
have access to the "s" variable or equivalent in other examples. Unique
symbols are enumerated, so do not do the job.
- What are some examples of real-world applications where the
runtime security of private slots is necessary?
It really depends on what you mean by "necessary". As far as I'm
concerned, it'd be all application using third-party code and a
lot of websites embed a Google Analytics script, so that would be
a lot of them (looking forward to the day GA is being hacked by
the way :-) )
I want to see more along these lines. What is the security model for
"loading third-party" code and in what way do private slots help?
I'm realizing now that I may be off-topic. I'm not that interested
whether it's a new type of slot with the non-freezability property. I
only care that it's private (non-enumerable with Object.getOwnPropertyNames)
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). It'd be more appropriate to define this private properties
directly on the object if there is a commonality to what you wish
keeping to your self when considering sharing the object.
I don't know whether this justifies a new type of slot. Brendan's "none
of your business" argument has a point. Additionally, if you do not have
access to a private symbol, why should you be provided by default the
right to change related private property descriptors?
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
