Hi, Andrea, sorry for being late in my answer... :-( Thanks for the explanation! Well, in my opinion, we would better stick with MDC implementation in JS, because this way we can tell exactly what the code does to people who want to know what it is, and because it has passed by a whole lot of tests - it will be garanteed that we will not fall into bugs that the native implementation has not -.
Also, I don't know if you guys agree with me, but developers who might use a "jQuery.forEach" implementation probably will want to favor browsers with the native implementation, because of the performance gains, and probably will be aware of the counter-effects in non- compliant browsers (like slowdown on IE6 or 7, compared to the original "jQuery.each"). Well, it's a more conservative opinion, but I think it's a better start point... we could do performance hacks later, when automated tests would have already been done... what do you think, Andrea? Diogo On May 23, 7:30 am, Andrea Giammarchi <[email protected]> wrote: > Ok. This is the point. Array.forEach is mainly used with non Array objects. > This is because with an Array we'll simply use a.forEach() rather than > Array.forEach(a). > > The most common case about Array.forEach is with HTMLCollection, a live > object. > > Array.forEach(document.getElementsByTagName("div"), function(div, i, all){ > if(div.className == "remove-me") > div.parentNode.removeChild(div); > else if(div.className == "empty") > div.appendChild(document.createTextNode("not anymore")); > > }); > > Now, if you think how many nested divs we tipically have in our DOM, as soon > as you remove one of them with className "remove-me" the live object > changes. This means that next iteration will be on index + 1 but since we > removed a div we do not know which one will be the next one ( how many divs > have been removed with that operation ? ) > > In a classic panorama where the main container is a div itself, with other > nested main containers populated via Ajax ( or not ) if we remove a > container with hundreds of divs the lenght of the loop will be the wrong one > and for every nested container the loop has to check if(i in list) plus an > i++ or ++i operation plus the classic (i < len). Retrieve a length is not > that expensive as we think, specially because we do not usually deal with > 100.000 objects a time. The sum of three operations, described before, could > be more expensive. My idea is that for DOM collection we could avoid the > usage of if(i in this) because broken lists ( with missed indexes ) are > extremely rare. If we avoid that theroetically spec compilant check which is > practically useless, we can boost up performances but we still need to avoid > modified length problems. This is why in first vice-versa Array file I did > not care at all about the i in this or the i in list, cause for 1 out of > 100000 possibilities the list is broken, other 99999 times we will have a > slower loop. If we want a spec compilant implementation, well, the MDC > version could be the one, but I would not care about the typeof check ( an > error will be throwed in any case if the first param is not a function and > if it is an object with call method the script will not be cross-browser ) > and I would not cast the lenght at all, first of all because in that way we > could have cutted lengths ( with extremely long list ) and secondly because > a length property should always be a number. So, as summary, the only check > I would do is about typeof obj.lneght == "number" but again, more we control > all these weird cases that hopefully will never happen, more we slow down > the already slow browser: Internet Explorer. > > Hope I explained better my points. Regards > > 2009/5/23 diogobaeder <[email protected]> > > > > > Andrea, > > > I don't think I got your point with live objects and forEach... could > > you please give an example where the basic implementation (as shown by > > Mozilla) would not be adequate? > > > Thanks! > > > Diogo > > > On May 22, 5:29 am, Andrea Giammarchi <[email protected]> > > wrote: > > > Ok, MDC specs do not consider the length, so the most close is this > > > > Array.forEach = Array.forEach || function(obj, callback, scope){ > > > for(var i = 0, length = obj.length; i < length; ++i){ > > > if(i in obj) callback.call(scope, obj[i], > > i, > > > obj); > > > }; > > > > }; > > > > Sorry for that :D > > > > 2009/5/22 Andrea Giammarchi <[email protected]> > > > > > To be honest I wrote something a bit redundant, this one is better if > > you > > > > want to use the length. > > > > > Array.forEach = Array.forEach || function(obj, callback, scope){ > > > > for(var i = 0; i < obj.length; ++i){ > > > > if(i in obj) > > > > callback.call(scope, obj[i], i, obj); > > > > }; > > > > }; > > > > even more simple, isn't it? > > > > > The scenario with DOM is tipically this one > > > > > div > > > > div > > > > div > > > > div > > > > div > > > > > getElementsByTagName("div") will have length 5, let's say the first > > one, > > > > the outer div, match something we were looking for and we remove it. > > With > > > > above version of Array.forEach the loop will be instantly stopped at > > next i > > > > < obj.length, because it changed, while with cached length, not > > updated, the > > > > loop will go on other 4 times and the i in obj will always fail. I > > guess > > > > then this version is, generally speacking, faster. > > > > > I am going to investigate a bit more about FireFox native behaviour > > though. > > > > > Regards > > > > > 2009/5/22 Andrea Giammarchi <[email protected]> > > > > > Actually, the main usage of Array.forEach is with non Array, like live > > > >> objects. Since with DOM is easy to remove a node and the result of the > > live > > > >> object could be completely changed, do you prefere 100 useless if I in > > obj > > > >> or just a loop brek thanks to changed length? Dunno which is faster > > and the > > > >> performance problem is the if, necessary if you want specs like, not > > the > > > >> length. Regards > > > > >> On May 22, 2009 1:05 AM, "Robert Katić" <[email protected]> > > wrote: > > > > >> There is no need to take in consideration eventual length updates; > > > >> that slows considerably, and it is not garanted in any/each native > > > >> implementation: > > > > >>https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Global. > > .. > > > > >> On May 21, 5:39 pm, Andrea Giammarchi <[email protected]> > > > >> wrote: > > > > >> > IE8? obviously no, how can you pretend a browser that implemented > > > > >> defineProperty only for Window... > > > > >> > On Thu, May 21, 2009 at 4:11 PM, diogobaeder <[email protected] > > > > >> wrote: > > > Hmmm... close, I... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
