> You did not include variants of > > var i, a=[]; > for (i=0; i < 10; i++) { > a.push(print(i)); > } > print(a[3]); /* output is 9 */ > > in your list. I see related bugs on a regular basis.
That would be (7). The above should work. The problem only exists with functions (or rather, closures): var result = []; for (var i=0; i < 5; i++) { result.push(function () { return i }); } console.log(result[3]()); // 5 (not 3!) Code for adding event handlers via a loop is often similar. Either for-of or Array.prototype.forEach() help. > The other place I see regular bugs by intermediate coders is related to > 'this' in events; but I'm not sure if we can count that as a JS problem or a > DOM bug (Is that 9c in your list?) -- > > function A() { > this.a = 123; > } > A.prototype.p = function {alert(this.a)}; > window.onclick = new A().p; > > IIRC, clicking will alert undefined, as the event handler is invoked with > this as the event. IME, this is not what programmers mean when they write > that. > > We can work around it by changing the constructor: > function A() { > this.a = 123; > this.p = this.p.bind(this); > } > > but of course now we are over-allocating for no good reason IMO. Very > frustrating. Yes, that’s (9c). I would love for JS to make the distinction between reading a property and invoking a function. Then one could automatically bind if a method is read. But that doesn’t seem to be in the cards. > #3 on your list is entertaining, I have been told that == is faster than === > in at least one implementation, because that's what sunspider tests. http://jsperf.com/equ-vs-strict-equ It seems that strict equals is usually faster. > On 30 December 2012 16:22, Axel Rauschmayer <a...@rauschma.de> wrote: > [Starting a new thread, just in case.] > >>> I made a list of the 10 biggest JS pitfalls and most of them will be gone >>> under ES6. Much less to worry about, much easier to learn. >> >> Could you share your 10-biggest list? > > > 1. Both undefined and null [not too much of a problem, easily learned] > 2. Truthy and falsy values [not pretty, but I’ve grown used to them and the > convenient but sloppy “has a value” checks via `if`] > 3. == [easy fix: always use ===] > 4. Parameter handling [fixed in ES6] > 5. Array-like objects [not completely fixed (DOM...), but `arguments` becomes > obsolete in ES6] > 6. Function-scoped variables [`let` FTW in ES6] > 7. Accidental sharing of data [for-of will help in ES6] > 8. Creating sub-constructors is messy [fixed via classes and `super` in ES6] > 9. `this` in non-method functions: > 9a) Referring to the `this` of a surrounding method, > 9b) accidentally creating globals by forgetting `new`, > 9c) using methods as callback functions > [(a) and (b) fixed by ES6 arrow functions and ES5 strict mode] > 10. The for-in loop [simple rule: avoid if you can, already possible in ES5] > > Thus: 1-3 won’t go away soon. 4-10 are mostly eliminated by ES6. > > Deliberate omissions: > - Implicit conversions are messy (and a superset of pitfall #2), but seem to > surprise people much less than the above items. > - Modules close another important hole in JavaScript, but I wouldn’t consider > that hole a pitfall. > > There are more pitfalls, but these seemed the biggest ones. > > -- > Dr. Axel Rauschmayer > a...@rauschma.de > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > Wesley W. Garland > Director, Product Development > PageMail, Inc. > +1 613 542 2787 x 102 -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss