2011/3/11 David Bruant <[email protected]>: > Le 11/03/2011 21:49, Charles Kendrick a écrit : >> Yes Allen, hence the urgency. If IE9 final ships that way, the "goose >> is cooked": > Let's face it right now: IE9 will ship that way. They're on RC phase, > it's completely irrealistic to consider they would change object > implementation. > From the spec point of view, there is no urgency since Harmony won't > ship for couple of years I think. > > >> 1. we will have a new de facto standard iteration order for Object >> that does not match any known use case - it is purely an >> implementation detail leaking through > As said by someone else, the iteration order has never been > standardized. It was dangerous from the developers to base their code on > an implementation detail even though this one was at some point > consistent accross browsers. Standards aren't only for implementors. > For the record also, a for..in loop looks into the prototype. It you > have an object and shadow a prototype property, how is the order affected ? > If for two objects o1 and o2 which share the same prototype, how are the > prototype properties iterated? what happens when you play with prototype > properties and object properties afterward? > > Fixing for..in loops is a dead-end in my opinion. > > It doesn't stop the discussion for own properties. > > >> 2. the majority of real-world applications will be slowed down because >> developers will need to re-implement the very commonly needed >> LinkedHashMap behavior in JavaScript >> >> 3. developers will waste a bunch of time doing this when the language >> could have provided it > I agree on 2 and 3. > >> 4. developers will waste a bunch of time upgrading old sites and >> applications > They shouldn't have relied on a non-standard behavior in the first > place. They spared time in not taking the time to know the standard, > this comes at a later cost. > >> 5. JavaScript code will forever be more verbose than it needs to be >> wherever ordered maps are needed >> >> 6. JSON messages will forever be more verbose than they need to be, >> and result in larger JavaScript allocation and GC loads when >> eval()d/parsed > Apparently, JSON has been standardized as unordered. Maybe that the good > decision if the order really matters to you is to use another > interchange format. Interchange formats are created with a purpose in > mind, with use cases. Maintaining an order comes with an in-memory cost > and a cost from the serialization implementation point of view. JSON was > certainly thought to not have this cost. Is Douglas Crockford around to > confirm?
From http://www.ietf.org/rfc/rfc4627.txt : An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array. > If your use case doesn't fit the interchange format use cases, change of > interchange format (XML fits your need even though it's a bit more > verbose). Or create one? > > > > The idea of using value proxies > (http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies) to > override object initialization syntax sounds like a good compromise to > keep unordered objects as they are now and being able to fix backward > compatibility. It will require a bit of work, but it sounds realistic. > > Cheers, > > David > >> Against all this, we have various misunderstandings (thinking the >> iteration order of Array is being affected, etc), but finally only: >> >> 1. for certain unusual use cases, implementers of code that use lots >> of integer indexes will need to use Arrays for best performance - a >> perfectly reasonable optimization technique to require, in my opinion >> >> 2. there may, in the immediate term only, for some unspecified use >> cases which may well be very synthetic, be an advantage for JQuery, >> which may well vanish as JQuery evolves >> >> >> On 3/11/2011 11:37 AM, Allen Wirfs-Brock wrote: >>> On Mar 10, 2011, at 5:44 PM, Charles Kendrick wrote: >>> >>>> This behavior was perfectly consistent across all browsers until >>>> Chrome 6. I think it's more appropriate to say that Chrome is not >>>> interoperable with thousands of sites than to define interoperable >>>> behavior based on a minority browser's very very recent break from a >>>> de-facto standard that stood for 15 years. >>> >>> Note that it isn't just Chrome. IE9 also has similar behavior (at >>> least in its late platform previews, I don't have the RC installed yet) >>> >>> On IE9 preview 1.9.8023.6000 standards mode: >>> >>> var a={x:'x', 3:3, 2:2,1:1}; a.a='a'; >>> print(Object.keys(a)); //--> 1,2,3,x,a >>> print(JSON.stringify(a); //--> {"1":1,"2":2,"3":3,"x":"x","a":"a"} >>> var k=''; for (var e in a) k+=e+" "; >>> print(k); //--> 1 2 3 x a >>> >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
