Asynchroniczna pętla, Rozważania nad API Opcje

[Comandeer]

Pytanie natury czysto teoretycznej. Załóżmy, że tworzę sobie API dla pewnego projektu X i musi być ono de facto w pełni asynchroniczne. Oczywistym wyborem są tutaj obiecanki - wszak nikt nie lubi się babrać w callbackach.

Wszystko jest cacy, ALE (IMG:style_emoticons/default/wink.gif) Potrzebna jest mi asynchroniczna wersja pętli [].forEach - metoda X.each (żeby się nikt nie rąbnął z natywnym [].forEach; chyba żeby iść w coś typu X.forEachAsync?). Na każdym elemencie mogą być wykonywane operacje asynchroniczne i pętla powinna "czekać".

Na chłopski rozum implementacja powinna się opierać na Promise.all i każdy przepuszczany przez X.each element powinien być obiecanką. Tak na szybko "backend" czegoś takiego mógłby wyglądać np. tak (oczywiście pewnie będzie wyglądać ciut bardziej złożenie (IMG:style_emoticons/default/wink.gif) ):

Kod

var promises = [];

pool.forEach(function(item)
{
    var promise = toPromise(item);
    callback(promise);
    promises.push(promise);
});

return Promises.all(promises);

Zatem wywołanie X.each wyglądałoby następująco:

Kod

X.each(function(promise)
{
    
})
.then(function(returnValues)
{
    //po pętelce
});

User dostawałby po prostu dostęp do obiecanki - proste i przyjemne. Pojawia się jednak pewien problem: zaburza to koncepcję chainingu - przy takim wywołaniu nie dostaniemy pojedynczej wartości (a zatem mitycznego this) tylko tablicę dowolnych wartości (user może zwrócić wszystko w obiecance). W zależności od naszego widzimisię może to być dobrze lub źle (ale raczej źle). Stąd myślę czy nie ograniczyć możliwości usera wprowadzając pewien rodzaj nakładki, analogiczny do tego, jaką udostępniają np. taski asynchroniczne w Gruncie - user miałby dostęp tylko do funkcji done (z tym, że wówczas bebechy operowałyby raczej na pojedynczynm Promise a nie ich tablicy):

Kod

X.each(function(done)
{
    done(); //wszystko cacy
    done(jakakolwiekWartosc); //coś się zepsuło
})
.then(function(X)
{
    //itd
});

Tym sposobem w X.each().then na pewno uzyskamy z powrotem X, co np. w dalszej kolejności uprzyjemni obcowanie z biblioteką przy wykorzystywaniu generatorów.

Pytania brzmią:

• Czy oparcie bebechów tego czegoś na Promise.all/Promise brzmi sensownie?
  
• Czy lepiej udostępnić userowi dostęp do obiecanki wewnątrz X.each i nie mieć kontroli nad tym, co zwróci całość, czy dać mu jedynie dostęp do done i w pełni kontrolować to, co zostanie zwrócone?
  
• X.each czy X.forEachAsync? (IMG:style_emoticons/default/wink.gif) Chociaż pewnie każdy, kto pracował kiedyś z jQuery i tak wybierze 1. wersję

[by_ikar]

Cóż, jeżeli chodzi o wydajność, to tutaj są jakieś świeże testy: https://github.com/petkaantonov/bluebird/tr...aster/benchmark i według nich, natywne implementacje nie koniecznie są takie szybkie jakby się mogło wydawać. Z tego wszystkiego wychodzi, że when.js jest na prawdę kawałkiem dobrego kodu, bo to już chyba któryś z rzędu benchmark w którym when.js stoi na wysokim poziomie. Czas zrewidować chyba swoją wiedzę i przyzwyczajenia o Q (IMG:style_emoticons/default/wink.gif)