Le 12/03/2011 19:41, Brendan Eich a écrit : > On Mar 12, 2011, at 9:54 AM, David Bruant wrote: >> The little "issue" I see in returning 1) index properties in ascending >> order 2) all other properties in addition order is that there is a bit >> of information lost in the process: overall property addition order >> (index properties included). > This is an issue in theory. Beware _a priori_ reasoning about usability > issues. I fully agree. I don't have myself a decent use case for that. My point was just that if we standardize the order as in the strawman, we will have lost forever the possibility to retrieve overall property order...
> In practice both users and (especially) implementors Do Not Want indexed > properties enumerated in insertion order. ... but if especially implementors aren't willing to implement keeping overall property order, then I understand that losing such a potential can be considered at the spec level. > The proof is the use of for-in over arrays, still common enough, also advised > against (but that is like talking back to the tide). > >> What is the rational or use case behind having index properties at first >> for objects and then the rest of properties? > The "rationale" (such as it is) is that JS conflates lists and dicts in > objects, but users mostly think about one or the other. When combining > indexed and named properties, many users still want for-in to work sensibly > and that means the list properties first in index order, the dict properties > after in insertion order. I understand the practice of users. However, this practice has started to be forged at a time when the only cross-browser way to iterate over own enumerable properties was for..in + hasOwnProperty. This is a different story now (ES5) that we have all object introspection methods (except in Opera according to Kangax compat-table) and Array extras. I also would like to remind that the for..in enumeration order is used in different places (for instance the Object.defineProperties methods, which also means Object.create (second argument)). Losing the overall order in for..in loops also means loosing it for these methods. It also means loosing it for proxies if I use Object.defineProperties(myProxy, props), which will mean that even with proxies, I won't be able to perfectly track property insertion order. I'll have some dependency on the engine for..in order. So I was actually wrong when I said earlier in the thread that proxies could be used to implement OrderedObject. If users mostly think of JS objects as lists or dicts, would it make sense to provide methods such as Object.numericProperties(o) and Object.dictionaryProperties(o) (sorry, not very inspired for the name)? David _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
