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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to