Comment #126 on issue 164 by [email protected]: Wrong order in Object
properties interation
http://code.google.com/p/v8/issues/detail?id=164
I'm a developer who has hit this limitation with surprise too, and I desire
v8 implement objects as ordered and associative arrays. I understand the ES
standard does not require this, so my appeal is not to keep this item as an
Issue, but to move this to a Feature Request.
The points I'd like to rebut include:
1. that this ticket's type and status are correct
2. that the "Issue" discussed helps should stay as implemented for
performance and memory benefits
3. that the "Issue" can effectively be sidestepped to provide desired
results
For the first item, I see this Issue's status and type as creating
a "bicycle shed" and causing the item involved to become "paint". To lessen
this effect, I propose changing this "Issue" from a bug to a feature
request. Specifically, this is not "WorkingAsIntended", and I'd argue
that's the biggest reason why everyone posts here, and not for
the "Working" part as much as the "Intent" part. If V8 only grounds their
intent on implementing ES standards, and those standards don't enforce a
direction, then there plainly is no intent whatsoever. So if the "Issue" is
working by any form of "intent", my only choice at present is to assume the
V8 designers made their choice out of their own wisdom. From the discussion
above, I only gathered performance, memory, and standards as a purpose
for "intent". I question that wisdom in the subsequent points stated below.
As for item 2, I don't see this as helping performance when JSON is hurt.
My grounds for this are that JSON performs best and conserves the most when
it's information density is maximized. When you need to otherwise
post-process or "color" the data coming from JSON, you cause developers to
both put more load on the wire and increase the cost of TCP transfer (and
that only worsens if you can't use web sockets). I see copper and fiber as
both being a costly part of any application, and managing post-processing
of data is also costly to me as a developer. If you believe that
post-processing is still viable and/or trivial, see my next point.
And lastly item 3, I don't see workarounds, "hacks", or alternatives as
being an argument. This is a discussion about why this Issue should be
a "Feature" or "Bug" or "WorkingAsIntended". Posts should be directed at
arguing for or against that, not about whether so-and-so is a "good
developer" or should "eat the cost". The true argument is, in supporting a
language, would a given feature lend more or less to those utilizing the
language. If you argue that I can out of my own effort mitigate the
limitations of the V8 object, I argue back that you can implement the
feature in V8 without the limitation and neither require additional effort
nor cost any to the end developer. Don't forget that while it's expected of
V8 to implement ES5, it's not limited to this. Purely looking at V8 as a
product I challenge the choice to limit V8's object to dropping insertion
order. This is substantiated as, by my own observations, you'd only lose
the ability to create an "unordered" associative array. This unordered
flavor has only performance and size gains, but no added functionality.
These costs are very different from functional costs. I know the lunch
isn't free, but performance and size on a client are still not as big a
deal as performance over a wire (see previous paragraph) or functionality
which makes V8 plainly more competitive and productive.
Lastly, I'm aware I can point out these arguments inside an ES discussion,
and so I'll voice my opinion there too. That said, I also find it
meaningful and orderly to post my opinions, thoughts, and observations in
this feature/bug report.
In summary, I'm not sure why this discussion is so long either. This is NOT
a big deal and it's also NOT a bug. I'm a developer, I see this as a
feature, and I'd like it. If you want to lessen the hype this Issue has
gradually gathered, just file it in a different place. Bicycle shed no
longer... there's nothing to add if this is plainly a feature request...
but people will forever argue this if the discussion is about "intent". V8
always has the choice to implement this feature this way... it just makes
me more likely to choose a different JS interpreter that does implement the
features I desire.
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
