I think I have no problems with vice-versa :D I use jQuery mainy for Sizzle and some tricky method so I would implement directly Array.forEach if not present, rather than another jQuery method which aim is to clone specs ( so it should not be jQuery method )
You can simply include only this file at the top of your application (vice-versa has no dependencies intenrally) and problem solved, isn't it? http://vice-versa.googlecode.com/svn/trunk/src/Array.js Regards 2009/5/26 diogobaeder <[email protected]> > > 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 -~----------~----~----~----~------~----~------~--~---
