> 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.
```js
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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
