Le 14/02/2012 19:28, Jason Orendorff a écrit : > On Tue, Feb 14, 2012 at 5:02 AM, David Bruant <bruan...@gmail.com> wrote: >>> To be sure, this is assuming that iteration order is fixed for a given >>> implementation. If order is not specified, then I don't see why that >>> should be required either. >> It is not required, but it's what experience tells us from the for-in loop. > All right, but let's not make the mistake of only learning from our > own experience. > > Many other language communities have very specific relevant > experience. For example, there is a single dominant Java > implementation and a single dominant Python implementation. Have the > other implementations been forced to duplicate the dominant > implementation's hash table iteration order, because existing code > depends on it? Have the dominant implementations been forced to back > out memory management changes or hash table optimizations that would > affect iteration order? > > I don't think that has ever happened. Python hash codes differ from > version to version and from OS to OS. Jython has a completely > different hashing function from CPython, even for strings. Keep in > mind that hash tables are one of two core data structures in Python, > so if code could sanely depend on iteration order, it would. > > Of course code will depend on unspecified behavior when that > unspecified behavior is actually intelligible and useful. Experience > suggests hash table iteration order is neither. Interesting. I have to admit that I'm almost entirely ignorant of Python, but I have some basic knowledge of Java or at least know some heavy Java users, so I'll ask them if they know something on that topic and specifically if there was an impact on how they wrote code and transitionned from version to version.
It seems to me that web browser JavaScript has a particularity in deployment that no other language has. When a JS engine feature is deployed, people use it. Then, the engine may want to do some changes. If it does, the new engine must be able to run code using the changed engine as well as old code. If it fails on the later, it's what we call "breaking the web". It seems to me that no other programming language has such a constraint. Maybe some things were made not backward compatible in Java 7, but people have the choice to say "all right, I'll stay on Java 6 until I'm ready to move to Java 7". They have the time to study the changes, add new unit tests in their own code if they think things can break between 6 and 7. They can gradually change their code in some cases. This is not a choice web authors have. The consequence we've seen so far was web authors relying on underspecified behaviors and the need to later specify a de facto behavior. I understand the point about hashcodes, but what garantees that all implementations will choose hashcode based iteration forever? Maybe, one day, V8 will decide that it's better to iterate keys in reverse insertion order, because they'll have found some awesome algo/data structure. Maybe Node.js users will start relying on this order, forcing V8 to be stuck. Then, maybe some "best viewed on Chrome" websites (we all know they exist) will rely on this iteration order (because they won't care testing on other browsers), forcing de facto standardization (to prevent breaking the web) Maybe it won't happen, maybe it will. Is the risk worth taking? If, in the end, there is a de facto standardization of iteration order, maybe one engine will have the good performance benefit that is praised here, but we'll see what the performance in engines for which this order wasn't the first choice. Once again, is the risk worth taking? > Mark Miller is holding up the argument for determinism really well. And of course, determinism from the beginning would prevent this risk. > I'm not sure anyone disagrees with his points. We should look into > deterministic data structures and measure the performance. Indeed. I'm looking forward to have an eye on Tyler Close Waterken tables. David _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
