Wpis z mikrobloga

@Marmite: ah te mikrooptymalizacje. Nic do nich nie mam, ale dopiero jeśli są rzczywistym wąskim gardłem (np programowanie grafiki). W innym wypadku całkowita strata czasu. Szczególnie jeśli w grę wchodzi zarządzanie drzewem.
@regis3: Ale że jakie mukrooptymalizacje? Optymalizacją w tym wypadku jest juz bardziej użycie właśnie for..in (teoretycznie dużo szybsza niż np. Array.prototype.forEach), więc nie wiem czy pijesz do mojego komentarza czy kodu kolegi.
@regis3: Pętla for..in jest zła, dlatego uważam ze nie powinno się jej używać. Zwłaszcza w przypadku tablic, gdzie boleśnie demaskuje ona ich największą wadę - to, że są obiektami (a raczej to, że indeksy to tak naprawdę własności). Dla programisty to powinno zostać przezroczyste. Dlatego uważam że to powinno być poprawne rozwiązanie w tym wypadku
@Marmite: no tak, tylko IMO nie ma sensu poprawiać kodu z zewnętrznym javascripcie, który nie należy do ciebie (i właściwie do którego nie masz fizycznego dostępu). Co do używania "for in" z tablicami, zgadzam się. Mojego code-review by nie przeszło.
@regis3: Z tym że to nie było podyktowane kwetią optymalizacji, tylko tym, że ta pętla jest po prostu schrzaniona. Już prędzej polecam iterowanie Object.getOwnPropertyNames, w 99% przypadków (dane z dupy) i tak nie chcesz iterować po łańcuchu prototypów.