iteration order for Object

Charles Kendrick charles at isomorphic.com
Fri Mar 11 08:31:25 PST 2011


On 3/11/2011 2:39 AM, David Bruant wrote:
> Le 11/03/2011 00:48, Charles Kendrick a écrit :
>> == Expressiveness and Performance argument
>>
>> A very common use case where order preservation is desirable is
>> providing the set of options
>> for a drop-down list in JavaScript.
...
> This is one (very valid, intuitive and common) use case. What if I want
> to implement some sort of dictionnary and want keys to be ordered in
> alphabetic order?
> If the spec imposes one order, then people with other use cases have
> additional work. Since so far, the spec has never said anything about
> property ordering, it would create some biase to add to the spec one
> specific order.

If the spec doesn't impose an order, *everybody* has extra work because there's no default 
strategy that can be relied upon.

I have no problem with *multiple* strategies being available, as either a set of collection 
classes similar to Java Collections, or as strategy hints to Objects.

However as far as the default strategy, the highest value thing to do seems to me to impose the 
de-facto standard of 15 years - insertion order - which is a very useful behavior and will 
avoid thousands of websites having to compensate for a change in de-facto standard behavior.

> The point I am trying to make is that having keys and values as strings
> is required by the DOM API in order to create the option elements, so
> when you mention "2 Strings per property", this is work that has to be
> done anyway. This might even be cheaper to have strings created from
> parsing the source than "extracted" as object property names.

No - the difference is, if you eval a JSON Object, you either have 2 JavaScript Strings per 
property (or even more overhead than that in some scenarios), or you have a single JavaScript 
Object in which only the property values actually exist as Strings - the slots are implicit, 
only existing inside the underlying VM.  This has less memory footprint, less allocation 
overhead, less GC overhead.  It is far far faster to remove or replace keys with this structure 
as well.

Whether this is used to render a DOM as well, or for something else, can be treated as a 
separate issue.  Already, you have this tremendous efficiency at the data structure level, and 
you've preserved JSON's ability to encode an ordered object.


More information about the es-discuss mailing list