Hi Ralf, Am 19.01.2009 um 09:17 schrieb Ralf Nieuwenhuijsen:
>> IMHO, the additional convenience you get by adding these methods to >> the Array prototype are just not worth screwing with a core language >> element (even if other browsers offer them natively, which means they >> don't appear in for ... in iterations there). > > I would completely reverse that logic. The way you want to use an > array, is what you _should_ just use an ordinary object for. > > Secondly, (key in .. ) are supposed to list all methods. > > The real bug is that it doesn't do that in firefox because they are > built-in. A much better discussion would be how to solve _that_. As Fabian points out in a later message, the built-ins shouldn't be enumerated (sorry, I was too tired yesterday to realize this myself). And they aren't enumerated, not in Firefox and not in IE. That's not a problem, and it's not going to change in the future. The real problem is the way that qooxdoo tries to make the array behaviour of all browsers the same. At first, it looks like a nice idea to extend the array prototype of IE, but this is a "leaky abstraction". There are situations when the abstraction breaks in unexpected ways - in this case by leading to unexpected enumeration results. > All in all, the fact that (key in .. ) constructs don' t work > correctly on arrays by default in IE or Firefox actually proves the > opposite of what you were saying. That they are indeed special and > 'hacked in'. No, they are not. They are one of the very core features of JavaScript. If you really want to point out something that was "hacked in" or looks like an afterthought, look at arrays (more about that below)! > You wanted to use (key in .. ) constructs without it giving you > methods, unlike every other object which does give all its properties. No. As Fabian pointed out, built-ins are _not_ listed with for ... in. Otherwise, even using Object() would give you methods like "toString" when enumerated. > The reason was a sparse array. I already replied to Derrell that he's right about sparse arrays being a bad example. It was just the first usecase that came to mind for combining for ... in with arrays, but I agree that it doesn't really make a lot of sense. > You are aware that arrays in javascript do not work like arrays in > php, right? There is no such thing as a sparse array. If you have an > array where the value 'hello' is at indice 2, and the value 'world' is > at indice 1000. Then you have a block of 1000 pointers in memory. The > rest is just set to null. That is why you are not see-ing the built-in > mehtods. That is not intentional, that is because it _is_ a very > special and different datatype, that just behaves sort of like an > object. I'm sorry, but this whole paragraph is just plain wrong. Arrays in JavaScript do not behave like you describe them _at all_. I'm not familiar with PHP, so I can't comment on that comparison. But regarding memory handling, these two constructs behave exactly the same in JavaScript: var x = new Array(); x[2] = "Hello"; x[1000] = "World"; var y = new Object(); y[2] = "Hello"; y[1000] = "World"; In other words, an array in JavaScript is just an associative array (or JavaScript Object) with the addition of a few built-in methods and a length property. You can easily test that yourself. Just allocate a thousand arrays and perform the following on each of them: arrayInstance[1000000000] = "Hello"; Then watch the memory usage of the browser _not_ explode. Or simply read the ECMA spec. (Disclaimer: I haven't read the whole spec myself, but I found the array behaviour very confusing when I was new to JavaScript, so I looked it up.) Regards, Andreas J. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
