Comment #125 on issue 164 by [email protected]: Wrong order in
Object properties interation
http://code.google.com/p/v8/issues/detail?id=164
mn.medikoo: The problem is not that lazy developers can't think of a way to
programmatically re-order their object properties. The problem is that we
need to be able to specify values in a specific order (not necessarily an
order that can be defined by a function) and trust that will be preserved.
A list of shoe sizes, for example, would be something like "...12, 13, 1,
2, 3...". I don't want to force an ordering, I simply expect the language
to preserve the order as specified.
rowaasr13: The problem is not that lazy developers expect the JS engine to
automagically sort our object properties for us. We don't expect objects
to behave like a "sorted map", simply an "ordered map". The problem also
has nothing to do with whether a JS dev has or hasn't read the ECMA
standard. JS is very different from other languages, in that the standards
have been largely useless for most of the language's life. For years the
World's Most Popular Browser violated the standard more often than not, yet
developers were still tasked with writing functional applications for this
platform and other more-compliant platforms using the same code. If the
written standards aren't standard at all, what's the point in reading them?
Even today, an application written using only the ECMA documentation as
your guide would likely fail in some areas for some users on some browsers,
which is unacceptable. Only when all the major ECMA implementations (eg,
browsers) conform identically to the standard, and those implementations
gain a majority in the worldwide userbase will it be useful for developers
to start coding against it. Until then, we will all be writing JS code
that violates the standard (knowingly or not) in certain conditions or on
certain browsers. This isn't x86 where it's extremely rare to have the
same instructions produce different results on different CPU vendors (which
isn't a perfect counter-example, but you get my point).
The problem is that most JS developers for the past X-teen years have
relied on JSObject to function like an Ordered Map with keys and values.
The fact that the same structure also happens to represent objects and
their properties is simply an unfortunate coincidence. Developers have been
assuming all this time that a JSON "object literal" (either written inline
or returned from AJAX) is actually a "map literal". This is a natural
assumption: the entire HTML document is one giant ordered literal object.
We JS devs tend to view the world and our code in "document order":
* Our code will execute top-to-bottom
* If I enumerate the children of this div, they will be enumerated
top-to-bottom
* If I insert this new element X before element Y, X will appear visually
above Y (where "above" is a relative term)
* (natural, but apparently now-incorrect assumption) If I construct a
JSON object and carefully order the members in a way that makes sense in
the real world, that order will be preserved later during enumeration (for
text insertion, object creation, whatever). This is exactly the problem
described by the OP.
In HTML / DOM, order is very important, and not just because we want things
in alphabetical order. There are usually some other human elements
involved. Size 13 shoes should appear before Size 1 just as January should
appear before February. Forget performance or memory usage, this is a
basic fundamental requirement. This is something that JS devs have assumed
the language is capable of for years, because in most historic
implementations it was. Whether JSON objects are the proper vehicles for
this functionality or not is another discussion, but I believe enough
precedent has been set that you cannot now say this cornerstone of
functionality has been an accident all along and JS was never meant to
support this.
We need the ability to provide a literal mapping object that preserves
order. I understand there are several implementations of OrderedMap
classes, but the whole issue is in declaring object *literals*. In today's
world of JSON and AJAX, we need to be able to communicate this concept of
an ordered map from server to client. AJAX servers need to be able to
communicate Map objects whose key/values are in a specific order and trust
that the client will receive those key/values in the same order. To have
the JS engine step in mid-transfer and re-order the object values is
completely unacceptable.
To a lesser extent, static literals defined inline should also always be
preserved. Just like the entire rest of the [X]HTML document is
order-preserved, an object literal that reads in a specific order from
top-to-bottom should enumerate in that same order so it can be rendered
into the DOM in that same top-to-bottom order.
To my knowledge there isn't yet a special literal for this purpose, so JSON
objects are still the only option.
My favorite suggestion so far is in c106: consider string-of-int keys as
strings instead of ints. This allows developers to write ordered maps by
ensuring that all keys are defined as strings (even if those strings are
all-numeric). This also preserves the performance characteristics of arrays
and objects with integer keys.
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
