iteration order for Object
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
> 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.
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
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