-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Propose to tc39 without override mistake #105
Comments
Attn @phoddie @bmeck @jfparadis @dckc |
Decoupling |
One idea might be to add an option to
Object.freeze(Object.prototype, { cacheIntegrity: true });
const obj = {};
obj.toString = () => '[Overridden Object]'; // succeeds const proxy = new Proxy({ foo: 42 }, {
ownKeys(...args) {
console.log('ownKeys triggered');
return Reflect.ownKeys(...args);
},
isExtensible(...args) {
console.log('isExtensible triggered');
return Reflect.isExtensible(...args);
},
preventExtensions(...args) {
console.log('preventExtensions triggered');
return Reflect.preventExtensions(...args);
},
});
Object.seal(proxy, { cacheIntegrity: true }); // prints 'preventExtensions triggered'
assert(Object.isSealed(proxy)); // prints nothing
assert(!Object.isFrozen(proxy)); // prints 'ownKeys triggered'
Object.freeze(proxy, { cacheIntegrity: true }); // prints 'ownKeys triggered'
assert(Object.isFrozen(proxy)); // prints nothing |
If we propose a The const frozenObject = Object.create(null, { foo: { value: 42, enumerable: true } }, { sealed: true });
assert.throws(() => { frozenObject.bar = 'baz'; });
assert(Object.isFrozen(frozenObject)); The use cases for caching the integrity level creation are less clear, but it would look like: function Foo () {
this.a = 42
}
Foo.prototype = Object.create(
Object.prototype,
{
toString: {
value() { return `[Foo ${this.a}]`; }
},
},
{
sealed: true,
cachedIntegrity: true,
},
); |
When we were considering this change in 2019, I did not yet appreciate that a |
We should propose
harden
to tc39, together with whatever other primitive hardening/freezing/snapshotting primitives we need to cover our needs, including those of tc53 and Moddable.Should we propose that properties made non-writable,non-configurable by harden also act as if the override mistake were absent? As we've seen, shimming this everywhere with accessors is expensive. But done via a standard mechanism, the platform could fix this cheaply.
Note: There was already an attempt to just fix the override mistake in the language itself. That failed under testing --- a little old code was incompatible with fixing this, but enough code that no one was willing to ratify it. The best we can get is probably that new hardening/freezing/snapshotting mechanisms fix this. Since these mechanisms would be new, the fix would effectively be opt-in and not break old code.
The text was updated successfully, but these errors were encountered: