Re: Object.unfreeze, or similar API

> If the engine were to read these all in advance, this would cause a problem. No, my handler always provides the same function for a given trap name, so even if the traps were cached when the proxy is constructed, the code would still work. > Are we sure that all engines don't read the

Re: Object.unfreeze, or similar API

I see, so you're relying on the engine reading the handler object during the moment that the user of my `obj` will try to read `obj`, so if the engine tries to read something in the handler (that we haven't whitelisted) due to what the user is doing with `obj` then we throw the error. If the

Re: Object.unfreeze, or similar API

Hi Joe, I used a 2nd proxy as the handler in order to only allow the desired traps. Sure, I could have defined all blacklisted traps in an ordinary object, and make them throw an error. But this wouldn't be future-proof in case new traps are eventually added. Whitelisting is safer. -- Oriol

Re: Object.unfreeze, or similar API

Hello Oriol, why did you make two Proxies there? Does it serve some purpose not achieved with only one Proxy? - Joe */#!/*JoePea On Mon, Feb 19, 2018 at 12:35 PM, Oriol _ wrote: > > So, what if there was a way to unfreeze an object in the scope in which > the object

Re: Object.unfreeze, or similar API

The entire purpose of Object.freeze is that the frozen object *can never be altered again* (in the ways that freeze restricts, at least). Allowing an object to be unfrozen would violate that very critical security property. The same is true with seal and preventExtensions. Once locked down, an

Object.unfreeze, or similar API

Note that if you want to use the Proxy that way you will probably want to implement the setPrototypeOf and preventExtensions traps as well since, together with set, defineProperty and deleteProperty, they are the traps whose associated internal methods can have side effects on the target when the

Re: Object.unfreeze, or similar API

> So, what if there was a way to unfreeze an object in the scope in which the > object was frozen? I don't think the behavior of object operations should depend on the scope in which they are used. And I could understand undoing [[PreventExtensions]], just switch [[Extensible]] back to true

Re: Object.unfreeze, or similar API

That's actually very useful, thanks! I have plenty of cases where I wished I could pass an object without cloning it to ensure it isn't mutated from outside. And instead of creating the Proxy right when I will emit an event (for example), I could just store the proxy somewhere so it is long-lived

Re: Object.unfreeze, or similar API

You can just do: const proxy = new Proxy(obj, { set() { throw new Error(); }, defineProperty() { throw new Error();}, deleteProperty() { throw new Error(); } }) this.emit('some:event', proxy) Though, it seems like an exotic use case. On Mon, Feb 19, 2018 at 8:56 PM, /#!/JoePea