[sarveniusz]

foreach($rooms as $room) {
 if($room->isFree()) {
 return $room;
 }
}

Czy da się zrobić coś takiego w js? Czy muszę pisać w poniższy sposób?

var room = null;
 this.rooms.forEach(function(el) {
 if(el.isFree()) {
 room = el;
 }
 });

 return room;

#javascript #webdev

[Marmite]

@sarveniusz: return this.rooms.filter(function(room) { return room.isFree(); })[0]

[epi]

@sarveniusz: możesz zrobić tak:

return this.rooms.filter(function(room){ return room.isFree(); });

to Ci zwróci tablicę pustych pokoi ;)

[M.....r]

@sarveniusz:
var room = this.rooms.find(el => el.isFree())

[TwigTechnology]

@epi: @MKu8ar: Tylko, że z pehapa wynika, że on nie chce tablicy, a pierwszy wolny pokój. W domyśle pewnie jeszcze bez iterowania całej listy. Niby szczegół...

[epi]

@TwigTechnology: ale pobranie pierwszego elementu z tablicy to już chyba nie problem? ;)

[TwigTechnology]

@epi: jeżeli istnieje, to nie :)

[sarveniusz]

@Marmite: @epi: tylko, że w tym rozwiązaniu przegląda całą tablicę, a w php kończy się po znalezieniu pierwszego pasującego elementu.

[epi]

@sarveniusz: w takim razie zwykły for powinien się nadać ;)

[Marmite]

@sarveniusz: W takim razie zwykły for jest dla ciebie rozwiązaniem, jeśli tak bardzo przeszkadza ci ta milisekunda różnicy ( ͡° ͜ʖ ͡°)

[sarveniusz]

@Marmite: Milisekunda do milisekundy i różnica coraz większa, nie mógłbym spać jeśli coś byłoby niezoptymalizowane :D

[Marmite]

@sarveniusz: Skąd wiesz, jakie optymalizacje zachodzą pod spodem kiedy "wychodzisz" z pętli for? Przedwczesne optymalizacje to błąd.

[sarveniusz]

@Marmite: Ale co masz na myśli, bo nie bardzo rozumiem :D Podaj może jakiś przykład, w którym przerwanie pętli for po znalezieniu szukanego elementu jest gorsze od przeszukania całej tablicy, bo ja raczej nie potrafię sobie takiego wyobrazić.

[Marmite]

@sarveniusz: Ogólnie powinno się unikać instrukcji warunkowych w programowaniu ze względu na coś takiego jak pipelining w procesorze. Załóżmy przykładowo że masz 5 elementów do przeszukania, procesor sobie już wczyta wszystkie instrukcje do pipe'a i nie będzie potrzeby wycofywać żadnej z nich i zajmie to X milisekund. A w twoim przypadku może się okazać że element zostanie znaleziony więc zamiast przechodzić do następnego elementu trzeba będzie nagle zrobić return - a

[larvaexotech]

@Marmite:

Ogólnie powinno się unikać instrukcji warunkowych w programowaniu

ze względu na coś takiego jak pipelining w procesorze

Patrząc już pod kątem optymalizacyjnym to niekoniecznie unikać, ale powodować by heurystyka działała jak najlepiej. Skoro i tak wyjście z pętli będzie cache missem to optymalniej jest zrobić for(...) {} w którym wszystkie elementy będą trafiały w cache (isFree() == false) oprócz tego jednego elementu po którym zrobimy return i zdejmiemy funkcje ze

[Marmite]

@larvaexotech: Wszystko spoko, ale jaki jest cel rozważania takich rzeczy, kiedy liczba elementów jest na tyle mała, że nie powoduje zauważalnych spadków/wzrostów wydajności... Jakby tam było miliard elementów to jest pole do optymalizacji, a jak jest ich 10 to szczerze mówiąc nie ma to sensu.

algorytm kolegi ma złożoność od O(1) do O(n) natomiast Twój to zawsze O(n)

Z reguły i tak bierze się pod uwagę pesymistyczną złożonośc, więc oba mają

[larvaexotech]

@Marmite: Nie ma to żadnego sensu, szczególnie jeśli mówimy o javascripcie więc istnieje pierdyliard różnych innych narzutów wydajnościowych przy których sens tej dyskusji jest jeszcze mniejszy :)

Tak więc już bardziej praktycznie, pomijając kwestie wydajności, to gdy natrafisz na taką sytuację to zamiast filter prościej jest użyć czytelniejszego algorytmu:

let emptyRoom = rooms.find( r => r.isEmpty() );

https://developer.mozilla.org/pl/docs/Web/JavaScript/Referencje/Obiekty/Array/find

[Marmite]

@larvaexotech: Specjalnie nie dałem .find, bo jest z ES6, a założyłem że kolega chce ES5 :P