Comment #110 on issue 164 by [email protected]: Wrong order in
Object properties interation
http://code.google.com/p/v8/issues/detail?id=164
http://en.wikipedia.org/wiki/XMLHttpRequest
"The latest revision of the XMLHttpRequest Level 2 specification is that of
7 September 2010, which is still a working draft."
Seen as XmlHttpRequest is still a draft and not a solid standard yet so it
can change anytime, can we expect some backward incompatible tweaks and
modifications in near future to it also, in order to speed up some
benchmarks ?
I'd like to see someone justifying breaking changes to AJAX with "well, it
was not in written and approved standard, so it was your own fault you used
it like that, no matter that ALL the browsers worked in a same friggin
way". According to such attitude and the state of actual specifications vs
drafts in the current html5 era, developers should not be doing much
anything except fussing around and waiting.
In reality, browser makers are the ones who actually make up those
standards boards and they are the ones who are actually implementing those
features and improving the drafts/standards in the process. But instead of
improving the jsobject spec, it is kept purposefully vague to allow browser
vendors to get away with anything, even with breaking changes from all
other browsers, with an excuse "well, it wasn't in a written standard
actually, so you should not have expected it to work that way, no matter
that all the other browser vendors, including us, did it the same way for
years"...
And on a side note about memory consumption: I bet that using
[{key:value},....] or [key1,value1,key2,value2] style PLUS lookup map for
speed {key1:value1,key2:value2,...} will still take up more memory than
when using the "order of insertion" logic. So for actual implementations,
the memory savings are sort of nonexistant. And things require more coding
because you have to keep two variables instead of one, and use one of them
for sorted looping and other for value lookups when you have the key...
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
