On Jun 16, 2011, at 4:27 PM, Mark S. Miller wrote: > On Thu, Jun 16, 2011 at 4:23 PM, Brendan Eich <[email protected]> wrote: > On Jun 16, 2011, at 4:14 PM, Mark S. Miller wrote: > >> On Thu, Jun 16, 2011 at 4:05 PM, Brendan Eich <[email protected]> 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). /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
