Am 19.03.2007 um 12:24 schrieb Andreas Junghans: > 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.
Maybe correct. But I think that the native browser implementation is a lot faster. However you will slowdown the native, standard conforming methods, because of the wrapper function needed. > >> 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 question is how often you work on such structures. This is not really relevant in my opinion. > >> 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. Convenience is really a big point, yes. > > 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). Generally functions which are natively implemented are a lot faster. Just see see lastly occurred native implementation of getElementsByClassName. > > 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". It is not the reason. Sure. But as we have real hash-maps in JS, the cases where you need "for... in" for arrays are quite rare. > > 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). I don't agree. As mentioned above, I really don't see many useful cases, where this is even relevant. The convenience is a much stronger argument in my opinion. If we could simply say, that one can use all JS 1.6 language features is unbeatable (compared to "...maybe you can, but...") > >> 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?). Prototype had extended Object.prototype in early releases. I think they continue to extend Array.prototype, String.prototype, etc. because it is normally not critical. Regards, Sebastian > > 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 ------------------------------------------------------------------------- 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
