On Aug 25, 2011, at 7:56 AM, Mark S. Miller wrote: > [+es-discuss] > > On Thu, Aug 25, 2011 at 2:40 AM, Cameron McCormack <[email protected]> wrote: > +cc public-script-coord > -cc,+bcc public-device-apis > > On 25/08/11 7:38 PM, Andreas Gal wrote: > We should take this to the WebIDL list then. The order definitely > matters in practice for interoperability if people do for-in over DOM > objects. I had to debug breakage due to shifting properties around in > our DOM IDL before. > > OK. I avoided specifying enumeration order to avoid stepping on the > ECMAScript spec's given that it was likely to specify an order in the future. > Do you know what kind of order is required? > > +1 to leaving this issue to a future EcmaScript spec to pin down. The current > strawman, which is unfortunately not on the table for ES6, is > <http://wiki.ecmascript.org/doku.php?id=strawman:enumeration>. I encourage > implementors to follow this when possible and post to the list cases where it > isn't. If we can get all implementors on board with this, as least for strict > or ES6 for/in loops, then it becomes de facto and would become a shoo-in for > ES7. > > Andreas, IIRC, you ran into a case in *Monkey where you did decide to deviate > from this strawman for efficiency reasons. Could you explain the issue? Is > there a standardizable variant of that strawman that you could implement > efficiently and that we could get broad agreement on? If so, we should try.
We switched to a snapshotting model a while ago. At the start of the enumeration we create an enumeration object with a list of properties. My secret hope was I can get away with breaking the property deletion suppression behavior of for-in. That turned out to be not the case. We broke a bunch of major web sites and had to back off of that. We now do a snapshot, and every delete scans all currently pending iterations and removes that property from the list. We do not add new properties to iterators during iteration. This optimization fails in 2 cases: cross-context and generators. Neither is currently modeled in TC39, so it would be difficult to address these cases. Where we don't stick to property creation order for for-in is dense arrays. Those are optimized into a representation where creation sequence is lost. To make things more exciting, dense arrays can become regular objects if certain things happen to them (denseness falls below 25% for example). In that case we re-create a regular object, and all future property additions will be visible in proper sequence. I think most browsers optimize dense arrays in similar ways, and its pretty critical for performance. Andreas > > -- > Cheers, > --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
