A case for removing the seal/freeze/isSealed/isFrozen traps

[David Bruant]

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