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. Mark Miller is holding up the argument for determinism really well. I'm not sure anyone disagrees with his points. We should look into deterministic data structures and measure the performance. -j _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
