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.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
