Hi,
The main use case (correct me if I'm wrong) for freezing/sealing an
object is sharing an object to untrusted parties while preserving the
object integrity. There is also the tamper-proofing of objects everyone
has access to (Object.prototype in the browser)
In a world with proxies, it's easy to build new objects with high
integrity without Object.freeze: build your object, share only a wrapped
version to untrusted parties, the handler takes care of the integrity.
function thrower(){
throw new Error('nope');
}
var frozenHandler = {
set: thrower,
defineProperty: thrower,
delete: thrower
};
function makeFrozen(o){
return new Proxy(o, frozenHandler);
}
This is true to a point that I wonder why anyone would call
Object.freeze on script-created objects any longer... By design and for
good reasons, proxies are a subset of "script-created objects", so my
previous sentence contained: "I wonder why anyone would call
Object.freeze on proxies..."
There were concerned about Object.freeze/seal being costly on proxies if
defined as preventExtension + enumerate + nbProps*defineProperty.
Assuming Object.freeze becomes de-facto deprecated in favor of
proxy-wrapping for high-integrity use cases, maybe that cost is not that
big of a deal.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
