I remember Allen brought up some concerns before about the strictness of the "fix" trap as well. The same idea could be applied there, such that a proxy author could return a non-object value if they want to still be able to intercess, and they could explicitly throw a TypeError if they want to indicate that the object cannot be made non-extensible / sealed / frozen.
On Thu, Jun 16, 2011 at 8:15 AM, Sean Eagan <[email protected]> wrote: > Sorry, I meant remove the configurability check of the > "getOwnPropertyDescriptor" and "getPropertyDescriptor" trap return > values, and add a check as to whether the "defineProperty" trap return > value is an object to fix the property to. > > On Thu, Jun 16, 2011 at 8:12 AM, Sean Eagan <[email protected]> wrote: >> How about *optional* property fixing as a compromise? We could >> replace the configurability check of the "defineProperty" trap return >> value with a check of whether the return value is an object, in which >> case it would be treated as a property descriptor to fix the property >> to, otherwise the return value would just be ignored. >> >> On Thu, Jun 16, 2011 at 4:18 AM, David Bruant <[email protected]> wrote: >>> Le 16/06/2011 00:53, Mark S. Miller a écrit : >>> >>> On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <[email protected]> wrote: >>> >>>> >>>> In a way, the fixed properties proposal make proxies bicephal. For some >>>> inputs (property names), they plug their handler-provided MOP-brain and >>>> for some others, they plug a native object MOP-brain (ES5 - 8.12). These >>>> brains cannot communicate. This is why changing .length in the "native >>>> object brain" has no effect in the other brain (which handles numeric >>>> properties(...unless some of these are non-configurable)). And I think >>>> it has been said before, but there would be no logging possible for >>>> non-configurable properties in the context of the fixed properties >>>> strawman since native MOP-brain doesn't allow that. >>> >>> >>> Cute metaphor. But as Tom's code showed, the proxy can create fixed >>> (non-configurable) accessor properties whose getters and setters form a >>> corpus callosum ;). >>> >>> Interactions with getter/setter is already a good thing, but I think it's >>> not enough. ES5 offers a very fine-grained API to study objects. If we >>> pretend to be able to emulate arrays based on proxies, we should be able to >>> emulate everything including answering correctly when it comes to "is it a >>> data or an accessor property descriptor?". >>> For instance, for a data property descriptor, even if non-configurable, >>> "writable" can be changed from true to false (then it cannot be changed >>> afterward). This behavior is not possible when dealing with getter/setters. >>> With fixed properties Tom's code, it is not possible to change an array's >>> length from writable to not writable. Trying to do so would throw an error >>> (because the property is non-configurable and any attempt to switch from >>> accessor to data property descriptor throw an error (or just reject?)). >>> >>> I'd like to insist on the ability for proxies to be able to emulate native >>> arrays (and new ES5 Object.* API interaction in particular) especially >>> because currently, SpiderMonkey has a problem with redefining ".length" on >>> arrays. See https://bugzilla.mozilla.org/show_bug.cgi?id=598996 >>> I wish proxies to be able to compensate if there is such a bug (in any ES >>> implementation) and I need this level of spec conformance. >>> This discredits the current fixed properties proposal (especially the >>> getter/setter compensation code), I think. >>> >>> David >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> >> >> -- >> Sean Eagan >> > > > > -- > Sean Eagan > -- Sean Eagan _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
