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

Brendan Eich brendan at mozilla.com
Tue Feb 12 05:29:18 PST 2013


Loss of identity, extra allocations, and forwarding overhead remain 
problems.

It seems to me that you are focusing too much on "share ... to untrusted 
parties." It's true you want either a membrane or an already-frozen 
object in such a setting. But the latter case, already-frozen object, 
does not want a membrane, both to avoid identity change and to avoid the 
allocation and forwarding overheads. And outside of untrusted parties, 
frozen objects have their uses -- arguably more over time with safe 
parallelism in JS.

/be

David Bruant wrote:
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list