[Harmony Proxies] Proposal: Property fixing

Mark S. Miller erights at google.com
Wed Jun 15 15:53:20 PDT 2011


On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <david.bruant at labri.fr> wrote:

> Le 15/06/2011 23:01, Tom Van Cutsem a écrit :
> > Just realized: even though an arrayProxy could update its fixed
> > "length" property, it would not be able to intercept updates "from the
> > outside" (i.e. updates to "length" by objects other than the handler).
> > I guess that capability is also needed to be able to "shrink" an array
> > if its "length" is decreased.
>

There's something I don't understand about this whole conversation. Why does
our emulated array need to claim that its length property is a
non-configurable data property, as opposed to
* a non-configurable accessor property
* a configurable data property
* a configurable accessor property
?
There can't be any ES3 code that would be broken by any of these other
choices, since ES3 code can't ask about these attributes.




> 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 ;).

-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110615/6a1f4a44/attachment.html>


More information about the es-discuss mailing list