Как стать автором
Обновить

Комментарии 22

Всё не осилил, но если я правильно понял — это какая-то порочная идея.

Может быть, стоит просто понять саму идею и писать так как оно получается в «натуральном» виде, чем пытаться как-то привести всё костылями к привычному?

Когда начал осваивать Node.js долго плевался на кажущееся неудобство. А когда понял и принял саму идею — всё стало клёво.

А тут КОП прямо-таки получается (костыльно-ориентированное программирование) :)

Это всё имхо.
Вы в nodejs еще столкнетесь с ситуацией, когда у вас будет 20 вложенных коллбеков, такой код читать и править — ад, это только одна из проблем асинхронного JS. Тогда вы вспомните про эту статью.
Ну так именованные функции решают. А часть из этих колбеков должна быть реализована в самом фреймворке, пусть и частично по типу приведённых выше библиотек. тогда и использование будет прозрачнее, и «лестничного» кода не будет.

А библиотеки эти, имхо, больше нужны не для создания цепочки коллбеков, а более сложных вещи, например «параллельного» выполнения нескольких функций передачей результатов всех по завершении дальше по цепочке. Если бы они ещё научились работать с web-workers для действительно параллельного, а не асинхронного выполнения — цены бы им не было.
Кажется, что с именованными коллбеками будет одна проблема — порядок выполнения как-бы разворачивается наоборот. Часто эти коллбеки отвечают просто за последовательные шаги какого-то алгоритма. Но сначала пишем обработчик коллбека, потом код, который его вызовет. Поэтому, чтобы понять логику выполнения, нужно постоянно код то снизу вверх читать (прыгая к обработчику), то сверху вниз (читая код обработчика) — в отличие от обычного синхронного кода.

У меня большого опыта тут нет, не подскажете — это решается чем-то вроде Module Pattern? Или нет такой проблемы совсем?
функции можно определять и после использования

function getData(){
}
getData( processData )
function processData( data ){
storeData( storeData )
}
function storeData( data ){
}
Согласен, важно понимать различие
var handler = function(){...}
от
function handler(){...}
но kmike наверное, имел ввиду то, что для него проблематично скроллить код от места вызова обработчика до описания обработчика и обратно, а вверх скроллить или вниз, в поисках кода обработчика, какая разница?
так объявлять функцию можно сразу после её использования и проблемы нет.
О, точно. Проблема значит выдуманная.
Посмотрите, к примеру, Step:

Step(
// Loads two files in parallel
function loadStuff() {
fs.readFile(__filename, this.parallel());
fs.readFile("/etc/passwd", this.parallel());
},
// Show the result when done
function showStuff(err, code, users) {
if (err) throw err;
sys.puts(code);
sys.puts(users);
}
)


* This source code was highlighted with Source Code Highlighter.
и вообще, почему у меня интервью не взяли?!? >_<

FAsyncPipe
( FCollector
( { code: function(){ fs.readFile( __filename, this ) }
, users: function(){ fs.readFile( "/etc/passwd", this ) }
}
)
, function showStuff( res ){
sys.puts(res.code);
sys.puts(res.users);
}
}
)

jsfiddle.net/FZqZN/3716/
Вы правы по поводу целей этих библиотек — они реализуют асинхронные шаблоны. Если использовать их, то проблема «лестничного» кода решается автоматически (лестницы критически уменьшаются до удобоваримых 2х-3х этажей) без именования коллбеков. И избавление от такого кода — первое, что может оценить человек, который пока не оценил или не разобрался с этими бибиотеками.
Это частично решаеться вынесением каждого калбека (или не каждого а только основной логики) в свое событие, и тогда когд сводиться только к генерации евентов
звучит как угроза =)
+1, мне тоже так кажется. «Каша» коллбеков обычно означает что одна функция пытается сделать слишком многое. Такое надо разбивать на подзадачи и каждую оборачивать в отдельную асинхронную функцию.
чувствую, что наличие столь большого числа библиотек, как Flow-js, является только свидетельством того, что Javascript на самом деле неудачен для параллельного программирования.

yess.jpg!!! В том смысле, что JS не настолько «идеален» для асинхронного программирования, как многие уверяют.

А вот эта ссылка — JavaScript Iterators and generators понравилась.
и какой вывод? что лучше использовать?
Полностью согласен с Isaac (slide-flow-control) — Напишите свой идеальный вариант.
За перевод спасибо!

Isaac — что не ответ, то шедевр, а главное по делу.

Жаль что JSDeferred не попала в список.
Не за что, хотя, конечно, много пришлось поработать над ним :)

Переводить Исаака было самым сложным :)
вместо перекладывания ответственности на прикладной код, умники, разрабатывающие браузеры, давно должны были сделать выполнение яваскрипта в нескольких потоках. например, чтобы разные блоки «скрипт тайп=яваскрипт» выполнялись в отдельных потоках, ну или как-то еще по-хитрому
раздули проблему из ничего, из-за того, что кто-то не хочет правильно делать программы
я щетаю так
Тогда сразу появляется проблема гонок и fine-grained locking.
У многопоточности свои проблемы. Считается что асинхронная обработка запросов как в nodejs позволяет достигать большей производительности чем многопоточная реализация по виду апача. Поэтому асинхронные библиотеки тоже нужны, но видимо пока нет стандарта де факто.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.