for-in evaluation order

[Dmitry A. Soshnikov]

On 27.12.2010 15:40, Andreas Gal wrote:
> I can't speak for other VM implementors, but I think most implementors will not want to guarantee either enumeration method (property addition order vs numeric order). In some cases we store array data "dense", in others we punt and use a natural object representation. The decision when we switch between representations is a brittle heuristics.

I see, so this heuristic decisions can spread also on a = {} in Firefox 
(I mean it's not currently guaranteed in exactly Firefox that the 
enumeration order of {} will be the same as specified by addition -- as 
we saw in the previous example)?

Can you also show a memory representation (at lower level) of "dense" 
and "sparse" (?) data. It will help to understand the advantages of 
choosing the needed order by implementers. It's not required to show it 
right now, but, if possible -- when you'll have a time to show it.

>   Allowing the underlying representation and along with it the enumeration order to bleed through is faster than normalizing (which in some cases would mean sorting property indexed names).
>

Yes, abstractly it's clear, but if to see the memory representation 
(since e.g. I don't know well C-level of representation well) it would 
be even better.

> That having said, if TC39 decides to standardize enumeration order, I am pretty sure we can make pretty much any standard enumeration order reasonably fast (maybe a little less fast than before though).

Hm, so it's not about serious technical performance issues and _any 
needed_ order can be implemented. I see, thanks.

>   Mark suggested at some point enumerating indexed properties first in numeric order, and then all remaining properties. Its the most sensible approach I have heard so far.

It seems sensible (again -- abstractly), but if to see the memory 
representation, it would be even more sensible.

>   If someone drafts a proposal to standardize enumeration order, I volunteer to implement it in Firefox and get some performance data. That would help calming implementor's nerves.
>

Hm... It's not so hard to describe the algorithm abstractly. But I am 
not aware about which implementation performance issues it may follow.

Dmitry.

> Andreas
>
>> It's interesting. Could you summarize these objections?
>>
>> Dmitry.
>>
>>