> 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 (for ordinary objects). But unfreezing makes no 
sense. How is ES supposed to know which properties became non-configurable 
because of `Object.freeze` and which ones were manually defined as 
non-configurable? Do you want all non-configurable properties to become 
configurable when "unfreezing"? I think that would be bad.

> // recommend all listeners to be synchronous, and not modify the payload later

You can recommend, but what if they are not synchronous? They will have a 
reference to the unfrozen object! If you trust them, you can avoid freezing in 
the first place. If you can't trust them, unfreezing is a big problem!

Frankly I don't see the point, if you don't want to clone just use a proxy that 
only allows restricted access.

let error = () => { throw new Error(); };
let allowed = ["get", "ownKeys", "has", "getOwnPropertyDescriptor"];
let handler = new Proxy(Object.create(null), {
  get(_, trap, receiver) {
    if (!allowed.includes(trap)) return error;
this.emit('some:event', new Proxy(obj, handler));

-- Oriol
es-discuss mailing list

Reply via email to