From: Thomas 'PointedEars' Lahn on 28 Oct 2009 07:16 Dmitry A. Soshnikov wrote: > Thomas 'PointedEars' Lahn wrote: >> [...] >> with `i' being the equivalent to an unsigned 32-bit >> integer value > > Not an integer, but converted to string (as property names of any > object - only strings). Therefore, too (all Numbers are floats), "equivalent". You want to check your dictionary (and the Specification). PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Thomas 'PointedEars' Lahn on 28 Oct 2009 07:33 kangax wrote: > Thomas 'PointedEars' Lahn wrote: >> kangax wrote: >>> Are you sure you haven't missed anything? >>> >>> "I would like to create own Object that would behave similar to Array >>> Object, but would have defined some methods that are not in current >>> ^^^^^^^^^^^^^^ >>> Array implementation. It need to not touch .prototype of an Array, so it >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> should work like this" >> >> So the thread has drifted a bit. Your approach touches ".prototype of an >> Array", too. That you are using `__proto__' to refer to said object >> instead, does not change that. > > Doesn't OP example make it clear what was meant by "touches"? If I > understood it right, the snippet with __proto__ setting doesn't "touch" > `Array.prototype`. But the OP did not say "not use Array.prototype" to begin with; they said: "not touch .prototype of an Array". And even if we assumed that ".prototype of an Array" is meant as "Array.prototype", there is still ambiguity as to what that is supposed to mean: a) a specific property accessor b) the object referred to by the value that the accessed property stores It stands to reason that "not touch .prototype of an Array" or "not touch Array.prototype" means (b), because the OP does not want to add (enumerable) properties to that object (see for-in). And your suggestion of using `[].__proto__' instead of `Array.prototype' in the source code does not help with that because `[].__proto__ === Array.prototype' where `__proto__' is supported. In fact, replacing the prototype object like you did decreases runtime efficiency; maybe negligibly, but IMHO needlessly. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: kangax on 28 Oct 2009 09:10 Thomas 'PointedEars' Lahn wrote: > kangax wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> kangax wrote: >>>> Are you sure you haven't missed anything? >>>> >>>> "I would like to create own Object that would behave similar to Array >>>> Object, but would have defined some methods that are not in current >>>> ^^^^^^^^^^^^^^ >>>> Array implementation. It need to not touch .prototype of an Array, so it >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> should work like this" >>> So the thread has drifted a bit. Your approach touches ".prototype of an >>> Array", too. That you are using `__proto__' to refer to said object >>> instead, does not change that. >> Doesn't OP example make it clear what was meant by "touches"? If I >> understood it right, the snippet with __proto__ setting doesn't "touch" >> `Array.prototype`. > > But the OP did not say "not use Array.prototype" to begin with; they said: Of course he did. You just seem to have missed it again. Look at the second comment of OP's example. var a = [2,4,6]; a.someAddedFunction(); // error - no Array .prototype extending ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Now look a bit further down: var c = new SuperArray([2,4,6]); [...] c.someAddedFunction(); // calls function ^^^^^^^^^^^^^^ How more clear should it be? > "not touch .prototype of an Array". And even if we assumed that ".prototype > of an Array" is meant as "Array.prototype", there is still ambiguity as to > what that is supposed to mean: > > a) a specific property accessor > b) the object referred to by the value that the accessed property stores > > It stands to reason that "not touch .prototype of an Array" or "not touch > Array.prototype" means (b), because the OP does not want to add (enumerable) > properties to that object (see for-in). And your suggestion of using > `[].__proto__' instead of `Array.prototype' in the source code does not help > with that because `[].__proto__ === Array.prototype' where `__proto__' is The fact that `[].__proto__` and `Array.prototype` reference same object is irrelevant here. The idea is to make sure `[]`'s [[Prototype]] references another object (i.e. inject that object into a scope chain of `[]`). Changing `Array.prototype` would, obviously, change what `Array.prototype` references, not what `[]`'s [[Prototype]] references. I still don't see your point here. > supported. In fact, replacing the prototype object like you did decreases > runtime efficiency; maybe negligibly, but IMHO needlessly. You mean now that we have one more object in prototype chain? Sure it does, but, as you said, this is very likely so negligible that there's no need to worry about it. -- kangax
From: Asen Bozhilov on 28 Oct 2009 14:09 On 28 ïËÔ, 01:07, VK <schools_r...(a)yahoo.com> wrote: > Because it iterates over object properties, not over array members. That is not true. What are you mean with "array members"? If you mean decimal unsigned 32 bit indexes, you are not right, because they are properties of that object. e.g. var a = ['test']; window.alert('0' in a); These properties is like any other properties of `object' in JavaScript. When you getting value, you getting from prototype chain. See below: Object.prototype['0'] = 'test'; var a = []; window.alert(a[0]); For array objects for-in is feature. Only reason for me to stop using for-in loops for arrays, is code produced from another programmers, and JS lib who touched Array.prototype or anybody else `object' upward in prototype chain. Regards.
From: Dmitry A. Soshnikov on 28 Oct 2009 16:23
On Oct 28, 9:10 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > > But for-in loops is also not so useful (it's slower) as for-length > loops as they analyze prototype chain (for all that [push], [pop] and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > so on properties) and make the check on any iteration such as [if (! > property.isEnumerable()) continue;]. > A little correction. Sure, prototype chain analysis can take place for array and with [for-length] loops (but regardless for-length loop itself - just via [[Get]]-method): Array.prototype[0] = 10; var a = []; a[1] = 20; for (var k = 0, length = a.length; k < length; k++) { alert(a[k]); // 10, 20 } But that's possible only again for sparse arrays, in normal case (ordered indexes, 0-based started) this situation cannot be. |