On Mar 12, 2011, at 11:27 AM, Charles Kendrick wrote:
> On Mar 12, 2011, at 10:41 AM, Brendan Eich <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
