[Harmony Proxies] Proposal: Property fixing

Tom Van Cutsem tomvc.be at gmail.com
Thu Jun 16 07:55:56 PDT 2011


Note that my idiom of turning non-configurable data props into accessor
props was just that: an idiom. It's not in any way enforced by the strawman.

If one is dealing with e.g. a non-configurable data property whose [[Value]]
is bound to a function, then one  can imagine a handler returning:

{ value: function(...args) { return handler.get(name)(...args); },
  writable: desc.writable,
  enumerable: desc.enumerable,
  configurable: false }

Or sometimes the handler may not even need to continue to intercept access
to a property, and may just return the original descriptor.

(Also: I just updated the strawman such that the defineProperty trap would
still be triggered on fixed properties, which should allow proxies + this
strawman to faithfully emulate Array "length")

Cheers,
Tom

2011/6/16 David Bruant <david.bruant at labri.fr>

> **
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110616/cf98ee17/attachment-0001.html>


More information about the es-discuss mailing list