iteration order for Object

Brendan Eich brendan at mozilla.com
Sat Mar 12 15:47:43 PST 2011


On Mar 12, 2011, at 11:27 AM, Charles Kendrick wrote:

> On Mar 12, 2011, at 10:41 AM, Brendan Eich <brendan at mozilla.com> wrote:
> 
>> On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
>> 
>>> The little "issue" I see in returning 1) index properties in ascending
>>> order 2) all other properties in addition order is that there is a bit
>>> of information lost in the process: overall property addition order
>>> (index properties included).
>> 
>> This is an issue in theory. Beware _a priori_ reasoning about usability issues.
>> 
>> In practice both users and (especially) implementors Do Not Want indexed properties enumerated in insertion order. The proof is the use of for-in over arrays, still common enough, also advised against (but that is like talking back to the tide).
> 
> I don't understand why this is still being discussed as a single behavior across Array and Object.

It's an attempt to further unify, or if you prefer, conflate, arrays and objects.

It may be a mistake. The enumeration strawman is young, and we can revise it. In particular I think David's point about a record catalog wanting insertion order even when property names happen to look like indexes is a good one.


> If we define the iteration order as:
> 
> 1. Object: in-order including indices
> 2. Array: indices first
> 
> Then:
> 
> 1. There's no information loss going from Object literal to live Object
> 2. Array has the for..in behavior people expect

These are good points, especially in light of David Bruant's observation about enumeration order mattering more in the new ES5 meta-object APIs.


> 3. Object has a useful behavior (similar to Java LinkedHashMap) instead of a surprising behavior (treating indices specially)

The argument from Java leaves many cold. Best to focus on backward compatibility and consistency in one dimension (not with Array; rather, consistent insertion order, no matter the property's name).


> This is aside from the performance and backcompat benefits covered previously.

The performance benefits are secondary, but you're ignoring the benefits of the strawman for those who (for whatever reason) use objects as if they were (dense, optimizable) arrays. This happens, you've seen some of the references. Perhaps these people should rewrite their code, but now we are in a perverse game: Chrome and possibly other browsers (I haven't tested IE9) optimize their code better than other browsers.

The backward compatibility point seems very strong to me, and I gather Chrome is feeling some heat still. We'll see how IE9 fares.


> You mentioned JS conflates Arrays and Objects - so - let's stop doing that :)

If only that genie could be put back in the bottle.

It would be helpful if V8 and Chakra people spoke to the question of preserving indexed property insertion order on non-Array objects.

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


More information about the es-discuss mailing list