Le 15/02/2013 11:03, Mariusz Nowak a écrit :
I've worked a lot with ECMAScript5 features in last two years, and I must say
I never found a good use case for Object.freeze/seal/preventExtensions, it
actually raised more issues than it actually helped (those few times when I
decided to use it). Currently I think that's not JavaScript'y approach and
use cases mentioning "untrusted parties" sounds "logical" just in theory, in
practice when actually we never include "untrusted" modules in our code base
does not make much sense.
However, main point I want to raise is that several times I had a use case
for very close functionality, that with current API seem not possible:
I'd like to be able to *prevent accidental object extensions*.
If something *accidental* can happen, then "untrusted parties" is more
than theorical ;-)
Brendan says it better [1]:
"In a programming-in-the-large setting, a writable data property is
inviting Murphy's Law. I'm not talking about security in a mixed-trust
environment specifically. Large programs become "mixed trust", even when
it's just me, myself, and I (over time) hacking the large amount of code."
"Security" and "untrusted parties" aren't about terrorists groups trying
to hack your application to get a copy of your database or corrupt it or
your choice to use some code downloaded from a dark-backgrounded website.
They're about you trying to meet a deadline and not having time to read
carefully the documentation and comments of every single line of modules
you're delegating to.
Trust isn't an all-or-nothing notion. Anytime I say "untrusted", I
should probably say "partially trusted" instead.
Trust also changes over time, mostly because as times passes, our brains
forget the invariants and assumptions we baked in our code and if those
aren't enforced at compile time or runtime, we'll probably violate them
at one point or another and thus create bugs. Or we just make mistakes,
because we're human and that's exactly the case you're explaining.
"Security" and "untrusted parties" are about our inability as human
beings to remember everything we do and our inability to be perfect. Any
"security" mechanism is a mechanism to protect against hostile outsiders
but also and probably mostly ourselves over time.
It is usually not considered so, but separation of concerns is a
security mechanism in my opinion. So are most object-oriented so-called
good practices.
"Security" is very loaded with emotions of people afraid to have their
password stolen and "cyber attacks". It's also loaded with the notion of
human safety and human integrity which, as human beings are sensitive to.
Maybe I should start using a different word...
I want to
control all enumerable properties of the object, so they can only be set via
defineProperty, but any direct assignment of non existing prop e.g.
'x.notDefinedYet = value' will throw. Imagine some ORM implementation, that
via setters propagates changes to underlying persistent layer, at this time
we cannot prevent accidental property sets that may occur before property
was actually defined (therefore not caught by the setter)
I assume that proxies will make such functionality possible, but maybe some
Object.preventUndefinedExtensions will be even better.
The problem is that there are probably dozens of use cases like yours
[2] and the Object built-in can't welcome them all.
Hence proxies as an extension mechanism of any "random
micro-abstraction" (as Andreas Rossberg puts it ;-) )
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-February/028724.html
[2] When I learned JS, how many time did I mistyped .innerHTML and
wasted hours not understanding where some "undefined" string in my UI
came from.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
