[Harmony Proxies] Proposal: Property fixing

Sean Eagan seaneagan1 at gmail.com
Thu Jun 16 06:25:57 PDT 2011

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 <seaneagan1 at gmail.com> 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 <seaneagan1 at gmail.com> 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 <david.bruant at labri.fr> wrote:
>>> Le 16/06/2011 00:53, Mark S. Miller a écrit :
>>> On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <david.bruant at labri.fr> 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>> --
>> Sean Eagan
> --
> Sean Eagan

Sean Eagan

More information about the es-discuss mailing list