On Tue, Aug 9, 2016 at 10:58 AM, doodad-js Admin <[email protected]> wrote:
> I think too much validation is not a good idea. Let the proxy lie. If you > don't, what is the purpose of Proxy? http://research.google.com/pubs/pub40736.html Of course, we can still agree that too much, by definition, is not a good idea ;). > I have a case where I wanted to force every new property to be read-only > through a Proxy so that, once created, they can no longer change. But I get > "TypeError" because of such a validation: > > ```js > "use strict"; > const proxy = new Proxy({}, { > set(target, property, value, receiver) { > if (Object.prototype.hasOwnProperty.call(target, > property)) return false; > Object.defineProperty(target, property, {configurable: > false, enumerable: true, writable: false, value: value}); > return true; > }, > defineProperty(target, property, descriptor) { > if (Object.prototype.hasOwnProperty.call(target, > property)) return false; > descriptor = Object.assign({}, descriptor, {configurable: > false, enumerable: true}); > if (!descriptor.get && !descriptor.set) > descriptor.writable = false; > Object.defineProperty(target, property, descriptor); > return true; > }, > }); > > proxy.a = 1; > proxy.a = 2; // TypeError: 'set' on proxy: trap returned falsish for > property 'a' > > Object.defineProperty(proxy, 'b', {value: 3}); > Object.defineProperty(proxy, 'b', {value: 4}); // TypeError: > 'defineProperty' on proxy: trap returned falsish for property 'b' > I don't understand the purpose of this code. From your description, don't you want these TypeErrors? Could you show a hypothetical test case that, if passed, demonstrates what you are actually trying to accomplish? > ``` > > -----Original Message----- > From: Claude Pache [mailto:[email protected]] > Sent: Tuesday, August 09, 2016 8:44 AM > To: es-discuss <[email protected]> > Cc: Mark S. Miller <[email protected]>; Raul-Sebastian Mihăilă < > [email protected]> > Subject: Re: Object.freezing proxies should freeze or throw? > > Given a Proxy that pretends to be in state A while its target is > observably in state B, and assuming that the target satisfies the > Invariants of the Essential Internal Methods [6.1.7.3], I claim that, in > order to force the Proxy to satisfy those Invariants, it is necessary and > sufficient to check that the two following conditions hold: > > * it is legal for an object to pass from state A to state B; and, > * it is legal for an object to pass from state B to state A. > > [6.1.7.3]: https://tc39.github.io/ecma262/#sec-invariants-of- > the-essential-internal-methods > > > Because I am too lazy to write the proof just now, I cowardly leave it as > an exercice to the reader. Meanwhile, that principle may be used to audit > the robustness of the Proxy specification. I have found the following bug > in Proxy.[[Delete]]() by applying the above principle to: > > * state A: nonexistent property on a nonextensible object; > * state B: existent own property on a nonextensible object. > > Resurrection of a successfully deleted property on a nonextensible object: > > ```js > var target = Object.preventExtensions({ x: 1 }) var proxy = new > Proxy(target, { > deleteProperty() { return true } > }) > > Object.isExtensible(proxy) // false > delete proxy.x // true > proxy.hasOwnProperty('x') // true > ``` > > After a first scan, I haven't found other bugs in the essential methods of > Proxy, than that one and the missing nonconfigurable-but-writable check in > [[GetOwnPropertyDescriptor]] and [[DefineOwnProperty]] already mentioned in > that thread. > > I plan to propose a minimal patch (i.e., just adding the missing checks) > in a few days. > > —Claude > > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
