[Harmony Proxies] Proposal: Property fixing

Brendan Eich brendan at mozilla.com
Thu Jun 16 16:30:04 PDT 2011

On Jun 16, 2011, at 4:27 PM, Mark S. Miller wrote:

> On Thu, Jun 16, 2011 at 4:23 PM, Brendan Eich <brendan at mozilla.com> wrote:
> On Jun 16, 2011, at 4:14 PM, Mark S. Miller wrote:
>> On Thu, Jun 16, 2011 at 4:05 PM, Brendan Eich <brendan at mozilla.com> wrote:
>> There is a second reason, mentioned recently: we are implementing the DOM on top of proxies, and the current WebIDL spec has non-configurable properties induced in its normative ES bindings from the IDL syntax. We want to match the spec.
>> Perhaps the WebIDL spec should be revised in exactly the same we we're currently talking about revised arrays?
> It's in Last Call, so time is short. Also, implementations do matter, and non-configurable is valued by implementations that want to optimize by assuming the slot in the object won't go away. If we make Array length, NodeList length, etc. be configurable, we implementors will need some *other* hidden attribute.
> There is already internal special case handling for every property that needs to be magical. So having non-delete-ability be part of this special case handling would seem natural. From your 
> > Bonus, I think this will simplify things in our implementation of Array length vs. the ES5 Object.* APIs.
> it might even be net more natural than the current situation.

My "Bonus" remark was *only* about Array length. For a great number of non-configurable properties (e.g. global vars in ES5 implementations, not created by eval), we JIT authors need a general attribute to consult. We aren't hardcoding, as we do for Array length (all the fast VMs optimize a.length expressions in the dense array, or any array, case).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110616/f7a41c2e/attachment.html>

More information about the es-discuss mailing list