Re: Contacts API -- attribute order

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 <cam@mcc.id.au> 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