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

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.

```javascript
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`/`Object.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.