Hi, Am 19.03.2007 um 11:14 schrieb Sebastian Werner:
> We only modifiy objects which needs to be filled with standard > features of JavaScript 1.6. This is to bring all browsers to the same > level. Otherwise we have to ignore these methods, even if available. > This would be a bad choice IMHO which even does not perform that well. From what I can see, these methods mostly handle cases where you have to examine every array element (at least until some condition is fulfilled). This in itself is already bad for performance. Code that uses this kind of "array walking" often enough to cause a noticable slowdown should probably be examined and changed (e.g. to use hash maps) anyway. > Using a array for hash like usage is generally bad. "Generally bad" is quite strong here. After all, an Array _is_ a hash map in JavaScript (just with an additional, automatically incremented length property). > You can iterate a > array a lot faster using the index. True. > There is normally no reason to > use the much slower key based iteration. Not entirely true. Consider the case of a weakly populated array. The length property will only tell you the highest index used (plus one), but not how many elements there really are. Yes, you could iterate over the whole array and check for undefined elements, but that wouldn't work so well if there are, say, 5 elements and the highest index is 10000, would it? > The decision to patch the client to JavaScript 1.6 was done months > ago. I currently think it is the best to keep the current behavior. > There are more arguments to keep the current behavior then to > change it. Could you state these arguments please? I can only see two: 1.) Convenience. However, calling a function with the array as the first argument would be only slightly less convenient. 2.) Performance. However, I'd like to see hard evidence for this. Are the JavaScript 1.6 native functions really measurably faster? And as I said, I don't think there are an awful lot of performance-sensitive use cases for the added functions (and most could probably be re- written to use hash like access). On the other side, I see some nasty consequences: 1.) Code that otherwise works fine breaks. Yes, it's faster to iterate over an array with an index, but that's no reason to break "for ... in". 2.) Code can behave differently in different browsers. Isn't one of the goals of qooxdoo to simplify development and not spend time with handling different implementations? But with the current code in qx.lang.Core, iterating over an array (or simply an object that you don't know/don't care is an array) yields different results in a JavaScript 1.6 browser compared to older ones. I agree with Derrell here - please don't change the Array prototype (much less without a _very_ strong warning to developers). > The other files found in the qx.lang excluding qx.lang.Generics only > create custom classes. Even if we modify the prototype in this case, > this do not result in cross-library incompatibility with other > libraries as our implementation completely fullfil the specification. How do you know that there are no incompatibilities? Some other lib may also implement these, and this other lib may not work according to spec (and may be used anyway because the application developer uses some beneficial parts from it). I think there even was such a case some time ago (was it the Prototype library?). Regards, Andreas ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
