poczytaj i po testuj albo kody związane z hasłem programowanie zdarzeniowe, albo poczytaj o wzorcu obserwator (w zasadzie chodzi o programowanie zdarzeniowe)...
js jest delikatnie ustawiony na inną filozofię - właśnie na tą zdarzeniową... samą zdarzeniówkę można wprowadzić na kilka sposobów - najprostszy (gdyż nie chcę tu rozwijać nie wiadomo jakich kwestii) to masz funkcję "nasłuchującą" w sensie sprawdzającą co jakiś warunek lub każde zdarzenie i w niej wywołujesz dalszy łańcuszek - więc w najprostszym modelu taka funkcja jest bardziej rozbudowanym if'em (ale to moje tłumaczenie ;p)...
więc na takie najprostsze spojrzenie to w tym kodzie co podałeś nie powinno być return a tak zwany callback uruchomiony (choć nie do końca - gdyż ta funkcja mogła być w kodzie w prostej wersji na żywca zapisana) - tak więc po jakimś zdarzeniu po prostu wywołujesz dalszy "łańcuszek" "pokarmowy" ;p np. w stylu:
mysqlc.query("SELECT * FROM za_users WHERE `id` = ?", [userId],
Kod
function(err, results) {
if (err) {
throw err;
}
self.data = results;
mojaFunkcja(jakis_opcjonalny_parametr);
});
i tu zapominasz o return prawie zawsze przy programowaniu zdarzeniowym a głównie skupiasz się na przekazywaniu zmiennych czy to jako parametr funkcji czy wcześniej zapisujesz do zmiennych "globalnych" lub prawie globalnych - w js to akurat zależy od tak zwanego zasięgu (czyli "scope") - "wolność Tomku w swoim domku"
w php niemal identycznie można pisać ale tak próbować to zalecam jedynie przy deamonach pracujących w tle zwłaszcza nasłuchujących na socketach (wkurza mnie limit z tymi intami i że to nie dopracowane - ktoś powie, że nie do tego język stworzony - język jest tylko narzędziem ;]) - ale ogólnie fajnie jest sobie logikę ułożyć zdarzeniowo nawet jeśli wewnątrz kod jest zawarty "na żywca"... - oczywiscie przy aplikacjach działających stale to w zasadzie pisanie zdarzeniowo to obowiązek ;]
