Comment #17 on issue 164 by charles.kendrick: Wrong order in Object
properties interation
http://code.google.com/p/v8/issues/detail?id=164
Very surprised to see this issue back to "WorkingAsIntended".
With respect to the new comments from Chromium devs:
1. to my knowledge, no one posting in any of the variants on this bug has
ever asked
for consistency in Array for..in iteration order, so the fact that other
browsers
have inconsistencies in Array for..in order is irrelevant. Everyone is
concerned
about Objects, and every other browser is consistent about Object iteration
order.
2. surely, treating Strings that can be parsed as integers differently from
other
Strings violates the principal of least surprise? After all, what's really
going on
here is that an implementation detail of Array is bleeding into the
behavior of Object.
3. the fact that the ECMA standard leaves this behavior unspecified is a
bad excuse
for not matching other browsers. Standards always follow implementations,
that's
where XHR came from, and Google does the same thing by implementing Gears
and then
embracing equivalent HTML5 functionality. The right fix is to have ECMA
formally
incorporate the de-facto standard behavior into the next rev of the spec.
4. Obviously, it is possible to fix this such that Arrays are not
affected. Most
likely this means it's going to be tricky to maintain the same performance
level, but
that's what you guys are good at, right?
I would also like to reiterate, this issue is much much more serious than
even
prominently broken websites - substantially all JavaScript frameworks
depend on this
behavior in various APIs, for example, stored-vs-displayed values for
drop-down
inputs. We are seeing side effects like scrambled orders in date/time
pickers, for
example, "01" and "10" not in the right order even when both are provided
as Strings.
As framework maintainers we have no way to address this problem without *AN
API
CHANGE*, eg, changing dozens of APIs so that you can pass an Array for
ordering in
addition to the Object that previously already conveyed the order. And
then we have
to ask all our customers to change their application code.
Furthermore, not having to maintain order *does not provide a speed boost*
in the
real world. It may show up as an advantage in synthetic benchmarks, but
the fact is,
in the large applications where JavaScript performance really counts, we
need the
order-preserving behavior in dozens of use cases. If we have to build an
equivalent
of Java's LinkedHashMap in JavaScript and start using that pervasively, no
matter how
much of a speed boost the Chrome engine gets from out-of-order properties,
*the net
result will be slower*.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
